Безопасность в Веб-разработке

17.4. Data Execution Prevention

17.4.1. Общие сведения

Data Execution Prevention (DEP) (Предотвращение выполнения данных) – функция безопасности, встроенная в семейство операционных систем Windows, которая не позволяет приложению исполнять код из области памяти, помеченной как "только для данных" [30]. Она позволит предотвратить некоторые атаки, которые, например, сохраняют код в такой области с помощью переполнения буфера. DEP работает в двух режимах: аппаратном, для процессоров, которые могут помечать страницы как "не для исполнения кода", и программном, для остальных процессоров. Эта функция впервые появилась во втором пакете обновлений для Windows XP.

С выходом в свет нового браузера Internet Explorer 8, пользователи все чаще и чаще стали встречаться с проблемами установки или работы ActiveX-компонентов. Все дело в технологии защиты памяти DEP (NX), которая призвана заблокировать потенциальные уязвимости в браузере [31, 32, 33].

В Internet Explorer 7 в Windows Vista была впервые представлена (выключенная по умолчанию) функция защиты памяти DEP, которая помогала избегать атаки из Интернета. В Internet Explorer 8 в Windows Server 2008, Windows Vista SP1 и Windows 7 данная функция по умолчанию включена.

DEP помогает избежать атак путем предотвращения запуска кода, размещенного в участке памяти, помеченном как неисполняемый. DEP в комбинации с другими технологиями, как ASLR, делает процесс использования взломщиками разнообразных уязвимостей, связанных с памятью (например, переполнение буфера) намного более сложным. Лучше всего данная технология работает для Internet Explorer и для загружаемых аддонов. Для обеспечения всех этих функций безопасности от пользователя не требуется никаких дополнительных действий и никаких запросов ему показано не будет.

В Internet Explorer 7 по причинам совместимости DEP по умолчанию был отключен. Несколько популярных аддонов были несовместимы с DEP и могли вызвать завершение работы Internet Explorer при включенном DEP. Чаще всего проблема состояла в том, что эти дополнения были скомпилированы с использованием старой библиотеки ATL. До версии 7.1 SP1 ATL полагалась на динамически сгенерированный код, который несовместим с DEP.

Новые DEP API были добавлены в Windows Server 2008 и Vista SP1, чтобы позволить использование DEP, сохраняя совместимость со старыми версиями ATL. Новые API позволяют Internet Explorer использовать DEP, при этом старые аддоны, использующие старые версии ATL, не станут причиной завершения работы Internet Explorer.

В редких случаях, когда дополнение несовместимо с DEP по какой-либо иной причине, отличной от использования старой версии ATL, опция в групповых политиках позволит организациям выключать DEP для Internet Explorer до тех пор, пока обновленная версия дополнения не будет развернута [34]. Локальные администраторы могут контролировать использование DEP, запустив Internet Explorer как администраторы и выключив опцию защиты памяти.

Это можно сделать, используя меню Сервис – пункт Свойства обозревателя – закладка Дополнительно [34]. Необходимо убрать галочку с пункта " Включить защиту памяти для снижения риска атаки из Интернета ", как показано на рис. 17.16.

Рис. 17.16. Контроль использования DEP в Internet Explorer

Источник: Безопасность IE8: технология защиты памяти DEP (NX) [34]

Другой способ отключения данной опции заключается в изменении параметра реестра DEPOff, который может, в зависимости от разрядности ОС Windows, располагаться в разных местах:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main]
"DEPOff"=dword:00000001

или

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main]
"DEPOff"=dword:00000001

Если значение параметра "DEPOff"=dword:00000001, то опция "Включить защиту памяти для снижения риска атаки из Интернета" – отключена.

Увидеть, какие именно процессы в Windows Vista защищены DEP, можно увидеть во вкладке диспетчера задач [34]. Для более ранних версий Windows можно использовать Process Explorer. В обоих случаях необходимо отметить опцию Data Execution Prevention в выборе отображаемых колонок.

17.4.2. Ключевые термины

Data Execution Prevention.

17.5. HTTPS

17.5.1. SSL

SSL (Secure Sockets Layer, уровень защищенных сокетов) – криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером [35].

Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причем для шифрования используется асимметричный алгоритм с открытым ключом. При шифровании с открытым ключом используется два ключа, причем любой из них может использоваться для шифрования сообщения. Тем самым, если мы используем один ключ для шифрования, то соответственно для расшифровки нужно использовать другой ключ. В такой ситуации мы можем получать защищенные сообщения, публикуя открытый ключ, и храня в тайне секретный ключ.

Протокол SSL состоит из двух под-протоколов: протокол SSL записи и рукопожатия. Протокол SSL записи определяет формат, используемый для передачи данных. Протокол SSL включает рукопожатие с использованием протокола SSL записи для обмена сериями сообщений между сервером и клиентом, во время установления первого соединения. Для работы SSL требуется, чтобы на сервере имелся SSL -сертификат.

SSL предоставляет канал, имеющий 3 основные свойства:

• Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма.
• Надежность. Обмен сообщениями включает в себя проверку целостности.
• Частность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений.

В протоколе SSL все данные передаются в виде записей, объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причем, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трем байтам. Код длины записи не включает в себя число байт заголовка.

Протокол SSL был изначально разработан компанией Netscape. Версия протокола 1.0 публично не выпускалась. Версия 2.0 была выпущена в феврале 1995 года, но "содержала много недостатков по безопасности, которые, в конечном счете, привели к созданию версии 3.0", которая была выпущена в 1996 году. Тем самым версия SSL 3.0 послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF) впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации, работающие с интернет деньгами, имеют лицензию на использование протокола SSL, для коммерческих целей в сети Интернет.

Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удаленного доступа на основе IPsec VPN. Но в виду ряда факторов: достаточная надежность и недороговизна – сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте.

Основными целями протокола SSL являются (в порядке приоритетности) [35, 36]:

1. Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.
2. Совместимость: Программисты, независимо друг от друга могут создавать приложения, использующие SSL, которые впоследствии будут способны успешно обмениваться криптографическими параметрами без всякого знания кода чужих программ.
3. Расширяемость: SSL стремится обеспечить рабочее пространство, в котором новые открытые ключи и трудоемкие методы шифрования могут быть включены по мере необходимости.
4. Относительная эффективность: работа протокола на основе SSL требует больших скоростей от CPU, в частности для работы с открытыми ключами. По этой причине SSL протокол был включен в необязательную сессию схемы кэширования для уменьшения числа соединений, которые необходимо устанавливать с нуля. Кроме того, большое внимание уделяется тому, чтобы уменьшить сетевую активность.

SSL поддерживает три типа аутентификации: аутентификация обеих сторон (клиент – сервер), аутентификация сервера с неаутентифицированным клиентом и полная анонимность. Всякий раз, когда сервер аутентифицируется, канал безопасен против атаки человек посредине, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами – это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения "finished". При посылке верного сообщения "finished", тем самым стороны докажут что они знают верный секрет (pre_master_secret).

В несколько упрощенном варианте диалог SSL представлен на рис. 17.17 [36].

Рис. 17.17. Диалог SSL

Источник: Процедуры, диагностики и безопасность в Интернет [36]

В SSL используются следующие алгоритмы:

• Для обмена ключами и проверки их подлинности применяются: RSA, Diffie-Hellman, ECDH, SRP, PSK.
• Для аутентификации: RSA, DSA, ECDSA.
• Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES, Camellia.
• Для хеш-функций: SHA, MD5, MD4 и MD2.

Опишем ряд атак, которые могут быть предприняты против протокола SSL. Однако, SSL устойчив к этим атакам [35, 36]:

• Раскрытие шифров

  SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA. SSL же делает такую атаку невыгодной, так как тратится большое количество времени и денег.
• Злоумышленник посередине

  Такая атака предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменивать сообщения. Злоумышленник представляется сервером для клиента и клиентом для сервера. Но такая атака невозможна при использовании протокола SSL, из-за того, что сервер использует сертификаты. А злоумышленник не имеет сертификата сервера.

  Замечание. Однако работа HTTS-фильтра (который устанавливает туннель в обе стороны и отдает свой сертификат клиенту) в MSForefrontTGM, работающая по этой схеме, не является атакой, но средством защиты и контроля.
• Атака отклика

  Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать (ИС), потому что он основан на наборе случайных событий. Однако злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать "верную" сессию, основываясь на код nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 2127 кодов nonce, чтобы получить вероятность угадывания 50 %. Но 2127 достаточно большое число, чтобы сделать эти атаки бессмысленными.
• Атака против протокола рукопожатия

  Злоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают 40 битное экспортированное шифрование, а некоторые даже 0 шифрование или MAC алгоритм, эти атаки представляют большой интерес.

  Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения Finished. Без секрета злоумышленник не может исправить сообщение Finished, вот почему атака будет обнаружена.