Список действий для безопасного инсталлирования и конфигурирования web-сервера

^ Список действий для безопасного инсталлирования и конфигурирования web-сервера
Безопасное инсталлирование web-сервера.

Конфигурирование управления доступом web-сервера со стороны ОС.

^ Конфигурирование безопасной директории web-содержимого.

Использование программ проверки целостности.

10. Лекция: Безопасность web-содержимого

Рассматриваются принципы обеспечения безопасности содержимого web-сервера. Перечислены различные технологии создания активного содержимого на стороне клиента и сравнивается создаваемая ими степень риска. Изучаются различные технологии создания динамических страниц на стороне сервера и связанные с ними уязвимости

Двумя основными компонентами безопасности web являются безопасность лежащих в основе приложения сервера и ОС, а также безопасность реального содержимого. Про безопасность содержимого часто забывают. Безопасность содержимого сама по себе имеет два компонента. Наиболее очевидным является правило не размещать частную, классифицированную или другую чувствительную информацию в публично доступном web-сервере, если не предусмотрена защита информации с помощью аутентификации пользователя и шифрования трафика. Менее очевидный компонент безопасности содержимого состоит в компрометации, вызванной некорректным способом обработки конкретных типов содержимого на сервере.
^ Опубликование информации на web-сайтах
Политика опубликования в web должна содержать следующие элементы:

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

Публичный web-сайт обычно не содержит следующую информацию:

Никогда нельзя использовать публичный web-сервер для хранения чувствительной информации, которая должна быть доступна только внутренним пользователям (компрометация публичного web-сервера обязательно приведет к компрометации этих данных).

Для гарантирования согласованного подхода организация должна создать формальную политику и описать процесс определения того, какая информация публикуется на web-сервере. Во многих организациях за это отвечает офицер информационной службы (Chief Information Officer — CIO). Такой процесс должен включать следующие шаги.

  1. Определить информацию, которая должна публиковаться в web.

  2. Определить целевую аудиторию.

  3. Определить возможные негативные последствия опубликования информации.

  4. Определить, кто отвечает за создание, опубликование и сопровождение конкретной информации.

  5. Создать или отформатировать информацию для опубликования в web.

  6. Просмотреть информацию на предмет наличия чувствительных данных.

  7. Определить соответствующий доступ и управление безопасностью.

  8. Опубликовать информацию.

  9. Проверить опубликованную информацию.

  10. Периодически просматривать опубликованную информацию на соответствие текущим требованиям политики безопасности.

Областью web-содержимого, про которую часто забывают, является информация, находящаяся в исходном коде HTML-страницы. Она может быть просмотрена из web-браузера использованием опции меню view source code. Разработчики часто не придают значения содержимому исходного кода их HTML страниц, даже если этот код содержит чувствительную информацию. Он может, например, содержать указатели на контактную информацию и показывать части структуры директории web-сервера. Атакующие могут проанализировать не только очевидное содержимое web-сайта, но также и исходный код; следовательно, web-администраторы должны проверять создаваемые HTML страницы своего web-сервера.
^ Обеспечение безопасности технологий создания активного содержимого
На ранней стадии развития web большинство сайтов предоставляли текстовую статическую информацию, основанную на ASCII. Никакой интерактивности не существовало между пользователем и web-сайтом за исключением того, что пользователь переходил по гиперссылкам. Однако вскоре появились интерактивные элементы, которые предлагали пользователям новые способы взаимодействия с web-сайтом. К сожалению, эти интерактивные элементы явились основой для появления новых уязвимостей.

Активное содержание на стороне клиента относится к интерактивным элементам, обрабатываемым web-браузером. Активное содержание может представлять серьезную угрозу для конечного пользователя. Например, оно может выполняться на машине клиента без явного разрешения пользователя. Существуют различные технологии создания активного содержимого. Некоторые наиболее популярные примеры включают ActiveX, Java, VBScript и JavaScript. Организации, рассматривающие разработку активного содержимого на стороне клиента, должны тщательно изучить риски для своих пользователей, так как использование активного содержания часто требует от пользователя понижения установок безопасности в своем web-браузере.

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

Все web-сайты, которые реализуют активное содержимое и генераторы содержимого, должны выполнять дополнительные шаги для защиты от компрометации.

Специальная осторожность также требуется при загрузке заранее созданных скриптов или выполняемых файлов из Интернета. Многие web-администраторы хотят сэкономить время, загружая свободно доступный код из Интернета. Хотя удобства очевидны, риск тоже велик. Существует много примеров вредоносного кода, распространяемого данным способом. В общем случае, никакие скрипты третьих фирм не должны быть установлены на web-сервер до тех пор, пока код не просмотрит доверенный эксперт.
^ URLs и cookies
URLs являются технологией адресации в Интернете. Существует несколько проблем безопасности, связанных с URLs. Так как URLs посылаются в открытом виде, любые данные, которые хранятся внутри них, могут быть легко скомпрометированы. Например, URLs записываются во многие места, включая логи web-браузера (например, история браузера), логи прокси-сервера и логи НТТР referrer. Тем самым хранить чувствительные данные, такие, как имена пользователей и пароли или указатели на ресурсы сервера, в URL не следует. Безопасность через неясность не является хорошей практикой.

URLs часто содержатся в содержимом web. Хотя эти URLs могут не показываться в браузере пользователя, они могут быть легко раскрыты просмотром исходного кода. Следовательно, никакое содержимое web-страниц не должно включать чувствительных URLs, спрятанных в исходном коде. Многие атакующие осуществляют поиск чувствительных URLs в исходном коде, которыми могут быть:

Cookie – есть небольшой блок информации, которая может быть записана на жесткий диск пользователя, когда он посещает web-сайт. Цель cookies состоит в том, чтобы позволить серверу распознать конкретный браузер и, в конечном счете, пользователя при повторном посещении данного сервера. В сущности, они добавляют состояние в НТТР-протоколе, в котором состояние отсутствует. К сожалению, cookies обычно посылаются в явном виде и хранятся в явном виде на хосте пользователя, тем самым, они уязвимы для компрометации. Существуют уязвимости, например, в некоторых версиях IE, которые позволяют нарушителю удаленно собрать все cookies без оповещения об этом самого пользователя. Следовательно, cookies никогда не должны содержать данные, которые могут быть использованы непосредственно атакующим (например, аутентификационная информация, такая, как имя пользователя, пароль).

Существует два типа cookies.

Cookies, которые являются причиной большинства проблем, называются постоянные (persistent) cookies. Эти cookies могут использоваться для отслеживания деятельности пользователя в течение всего времени и на различных web-сайтах. Наиболее общее использование постоянных cookies состоит в сохранении соответствия информации о пользователях между сессиями. Часто запрещается использование постоянных cookies на публично доступных web-сайтах.

"Сессионные (session)" cookies действительны только в течение одной сессии. Эти cookies истекают в конце сессии или по истечению определенного промежутка времени. Так как эти cookies не могут использоваться для отслеживания персональной информации, их применение обычно не запрещается. Тем не менее, они должны быть явно определены и описаны в регламенте web-сайта.
^ Уязвимости технологий активного содержимого на стороне клиента
Доступны различные варианты технологий активного содержимого на стороне клиента (web-браузера). Каждая технология имеет свои сильные и слабые места, но ни одна не является полностью безопасной. Обсудим некоторые наиболее популярные технологии активного содержимого и связанные с ними риски. (Однако следует помнить, что в каждый момент времени могут появиться новые технологии.) Web-администратор, который рассматривает развертывание web-сайта с возможностями, требующими технологии активного содержимого на стороне клиента, должен тщательно взвесить риски и преимущества данной технологии перед ее внедрением. В частности, web-администраторы должны помнить, что даже если содержимое сайта не представляет угрозы для пользователя, активное содержимое других сайтов может представлять угрозу и пользователь может забыть изменить установки безопасности в браузере на более безопасные.

Java – полнофункциональный, объектно-ориентированный язык программирования, который компилируется в платформонезависимый байт-код, выполняемый интерпретатором, называемым Java Virtual Machine (JVM). Результирующий байт-код может быть выполнен в том месте, где он был скомпилирован, или передан на другую поддерживающую Java платформу (например, передан с помощью HTML-страницы как апплет). Java используется для добавления функциональности в web-сайтах. Многие сервисы, предлагаемые популярными web-сайтами, требуют от пользователя иметь поддерживающий Java браузер. Когда web-браузер видит ссылки на Java-код, он загружает код и затем выполняет его, используя встроенную JVM.

Разработчики ^ Java в большинстве случаев успешно решают проблемы безопасности. Язык программирования Java и окружение времени выполнения обеспечивают безопасность первоначально с помощью строгой типизации, при которой программа может выполнять определенные операции только для определенных типов объектов. Java придерживается так называемой модели безопасности sandbox, использующей изолирование памяти и методов доступа, а также поддержку нескольких независимых доменов выполнений. Код Java, такой, как web-апплет, заключается в sandbox, который разработан для предотвращения выполнения неавторизованных операций, например, просмотр или изменение файлов в файловой системе клиента и использование сетевых соединений в обход защиты файлов.

Тем не менее, апплеты хоста представляют угрозы для безопасности, даже если выполняются внутри sandbox. Апплеты хоста могут использовать различными способами не предназначенные для этого системные ресурсы или могут заставить пользователя выполнить различные нежелательные действия. Примеры нежелательных действий апплетов на хосте включают DoS-атаки, подделку e-mail адресов, вторжение в частную жизнь (например, экспорт идентификации e-mail адреса и информации о платформе) и инсталлирование люков (backdoors) в систему. Так как модель безопасности Java является более сложной, пользователю может быть трудно понять ее и управлять ею. Такая ситуация может увеличить риск.

JavaScript – это кроссплатформенный скриптовый язык общего назначения, чей код может быть встроен в стандартные web-страницы для создания интерактивных документов. Название JavaScript является неправильным, потому что этот язык не имеет большой взаимосвязи с технологией Java и разрабатывался независимо от него. Внутри контекста web-браузера JavaScript является полноценным языком программирования, давая возможность заранее написанным скриптам выполнять определенные действия. Внутри данного контекста JavaScript не имеет методов для прямого доступа к файловой системе клиента или для прямого открытия соединений с другими компьютерами за пределами хоста. Более того, браузер обычно ограничивает выполнение скрипта той станицей, на которую он был загружен.

Теоретически ограничение языка скрипта границами web-браузера должно обеспечивать относительно безопасное окружение. На практике это выполняется не во всех случаях. Многие основанные на браузерах атаки используют скриптовый язык в сочетании с конкретной уязвимостью безопасности. Основной источник проблем двойной: существование изъянов в реализации в выполняемом окружении и скрытое связывание браузера с соответствующей функциональностью, такой, как клиент e-mail. Подобные внедрения включают посылку списка истории URL на удаленный сайт и использование e-mail адреса пользователя для подделки почты. Возрастающее использование HTML и других языков разметки в качестве содержимого электронной почты и в сервисах push-технологий может открыть новые бреши для внедрения ошибок с использованием встроенных скриптов.

Visual Basic Script (VBScript) – язык программирования, разработанный Microsoft для создания скриптов, которые могут быть встроены в web-страницы, просматриваемые с помощью браузера IE. Netscape Navigator, однако, не поддерживает VBScript. Подобно JavaScript, VBScript является интерпретируемым языком, который дает возможность обрабатывать скрипты на стороне клиента. VBScript, который является подмножеством широко используемого Microsoft языка программирования Visual Basic, работает под управлением Microsoft ActiveX. Язык подобен JavaScript и имеет аналогичные риски.

ActiveX – это множество технологий от Microsoft, которые предоставляют инструментальные средства для связывания desktop-приложений с web. Управления ActiveX являются переиспользуемыми программными компонентными объектами, которые могут быть присоединены к e-mail или быть загруженными с web-сайта. Управления ActiveX также могут быть заранее инсталлированы на Windows-платформе. Web-страницы включают управления ActiveX, используя скриптовый язык или с помощью HTML-тега OBJECT.

Модель безопасности ^ ActiveX значительно отличается от модели sandbox Java. Модель Java ограничивает апплет множеством безопасных действий. В противоположность этому, ActiveX не имеет ограничений на то, что он может делать. Вместо этого управляющие элементы ActiveX имеют цифровую подпись своего автора в соответствии с технологией, называемой Authenticcode. Цифровые подписи проверяются, используя сертификаты, выпущенные доверенными сертификационными центрами. Сертификационный центр должен гарантировать, что никакого опасного кода не будет сознательно распространено. Технология Authenticcode гарантирует, что управления ActiveX не могут быть распространены анонимно и что модификация управления может быть определена. Такой процесс сертификации, однако, не гарантирует, что поведение управления будет корректным.

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

Рассмотрим риск ActiveX в сравнении с другими популярными технологиями активного содержимого на стороне клиента.

^ Сравнение риска различных технологий на стороне клиента

Технология на стороне клиента

Степень риска

JavaScript и VBScript

Низкая

Java-апплеты

Средняя

Управление ActiveX

Высокая
^ Уязвимости технологий создания содержимого на стороне сервера
В отличие от описанных выше технологий, CGI, ASP и другие аналогичные интерфейсы сервера выполняются на стороне сервера в модели клиент-серверного взаимодействия. Обычное использование технологий создания содержимого на стороне сервера включает:

Приложения на стороне сервера могут быть написаны на многих языках программирования. Если эти скрипты не разработаны и не протестированы тщательно, атакующий может найти и использовать бреши в коде для проникновения на web-сервер. Следовательно, скрипты должны быть написаны с учетом безопасности, например, не следует разрешать выполнение произвольных команд в системе или запуск небезопасных программ. Атакующий может найти слабые места посредством проб и ошибок, и у него нет необходимости знать исходный код скрипта, чтобы обнаружить уязвимости.

Генераторы содержимого на стороне сервера могут создать уязвимости на сервере следующим образом:

Идеально, чтобы скрипты на стороне сервера ограничивали пользователей небольшим множеством хорошо определенных функциональностей и проверяли корректность длины и значений входных параметров, чтобы атакующий не мог переполнить память или заставить выполнить произвольные команды. Скрипт должен выполняться с минимальными привилегиями (не от имени администратора или root’а) для избежания компрометации всего web-сайта. Тем не менее, могут остаться потенциальные дыры безопасности, даже если приложения выполняются с минимальными привилегиями. Например, скрипт может иметь достаточно привилегий, чтобы отправить по почте файл с паролями системы, проанализировать сетевую информацию или просканировать открытые порты.

Уязвимость может потенциально воздействовать на весь web-сервер. Хотя чаще всего подобное происходит в CGI-приложениях, другие интерфейсы и технологии разработки серверных приложений также имеют изъяны. CGI, как наиболее ранний и часто используемый стандарт, приобрел большее значение за последние годы, но то же множество уязвимостей существует при использовании аналогичных технологий web-разработки на стороне сервера.

Common Gateway Interface (CGI) – CGI-скрипты определяют механизм, используемый для взаимодействия web-сайтов с базами данных и другими приложениями на стороне сервера. Существуют различные методы обработки информации на стороне сервера, такие, как Microsoft ASP для IIS-сервера, Java-сервлеты и РНР, поддерживаемые большинством web-платформ, включая Apache и IIS. Перечислим основные требования, которым должна удовлетворять лежащая в основе ОС:

Server Side Includes (SSI) – ограниченный скриптовый язык на стороне сервера, поддерживаемый большинством web-серверов. SSI предоставляет множество динамических возможностей, например, включение текущего момента времени или даты последней модификации HTML файла, и является альтернативой использованию CGI-программ для выполнения определенных функций. Когда браузер запрашивает документ со специальным типом файла, таким, как .shtml, это говорит о том, что сервер должен обработать его перед тем, как послать клиенту (web-браузеру). Команды SSI встроены в HTML комментарии (к примеру, file="standard.html"-->). Сервер читает файл и ищет HTML комментарии, содержащие встроенные команды SSI. Когда он находит их, он заменяет часть исходного HTML-текста выходом найденной команды. Например, команда SSI, приведенная выше (#include file), заменяет весь SSI-комментарий содержимым другого HTML файла. Это позволяет показать соответствующий логотип или другую статическую информацию, подготовленную в другом файле, для реализации унифицированного способа изображения во всех web-страницах. Некоторые доступные директивы дают возможность серверу выполнить произвольные системные команды и CGI-скрипты, которые могут создать нежелательные эффекты на стороне сервера. Вот некоторые проблемы, которые возникают при использовании SSI:

Microsoft Active Server Pages (ASP) – скриптовая технология на стороне сервера от Microsoft, аналогичная SSI, может быть использована для создания динамических и интерактивных web-приложений. ASP-страница представляет собой образец HTML, который содержит скрипты на стороне сервера, выполняющиеся, когда браузер запрашивает ресурс *.asp от web-сервера. Web-сервер обрабатывает запрошенную станицу и выполняет любые команды скрипта перед посылкой полученного результата браузеру пользователя. Поддерживаются скриптовые языки Jscript и VBScript, но могут быть включены и другие скриптовые языки, которые поддерживаются ASP-совместимым интерпретатором. Например, доступны скриптовые средства для языков PERL, REXX и Python. Скриптовые возможности могут быть расширены использованием объектов ActiveX, которые могут быть разработаны в различных языках, скажем, Visual Basic, C++, COBOL и Java. Скрипт, который включает объект ActiveX, может создать объект и передать ему необходимые входные параметры. Заметим, что ActiveX является необязательной технологией и не требуется для ASP.

Некоторые проблемы, которые следует рассмотреть при использовании ASP:

Тем не менее, существуют определенные гарантии от переполнения буфера.

Java Servlets – сервлеты, основанные на технологии Java и являющиеся Java-программами на стороне сервера. Web-сервер первым делом определяет, требует ли запрос пользователя динамически создаваемую сервлетом информацию. Если так, web-сервер может создать экземпляр объекта сервлета, соответствующий запросу, и вызвать его для получения необходимых результатов. Web-сервер обычно сам управляет жизненным циклом своих сервлетов. Следуя возможности портирования Java и обеспечивая общий прикладной программный интерфейс, объекты сервлета могут выполняться в любом окружении сервера. Сервлеты используют объектно-ориентированное окружение на web-сервере, которое является гибким и расширяемым. Более того, недоверяемые объекты сервлета могут выполняться в безопасной области, динамически создавая информацию, которая будет передаваться из безопасной области в оставшееся окружение сервера.

Основные особенности, которые следует учитывать при использовании ^ Java сервлетов:

PHP (Hypertext Preprocessor) – скриптовый язык, используемый для создания динамических web-страниц. Синтаксис РНР аналогичен С, Java и Perl, при этом код РНР встроен в HTML страницы для выполнения на стороне сервера. РНР обычно используется для извлечения данных из базы данных и представления их на web-странице. Большинство web-серверов на Windows и Unix поддерживают данный язык, и он широко применяется вместе с базой данных MySQL. Некоторые проблемы, которые следует учитывать при разработки на РНР:

При анализе или написании выполняемого активного содержимого или скрипта следует рассмотреть следующие вопросы:

При рассмотрении генератора содержимого на стороне сервера важно просмотреть различные базы данных уязвимостей (такие как ICAT метабаза, http://icat.nist.gov) для определения возможного риска использования различных технологий. Хотя история в полной мере и не отражает будущего возможного риска, на ее основе можно сделать вывод о том, какие технологии считаются более уязвимыми.

Различные организации исследуют безопасность сети и систем и периодически публикуют информацию, касающуюся раскрытых уязвимостей в ПО сервисов. Это включает ПО web-серверов и поддерживаемые ими технологии, такие, как языки скриптов и внешние программы. Внешние программы, которые широко используются, регулярно анализируются исследователями, пользователями, командами реагирования на инциденты безопасности и членами хакерского сообщества.

Хакеры часто публикуют скрипты, выполняющие внедрение, для известных уязвимостей в ПО web-сервисов и внешних программ, обычно используя для этого публичные web-сервера. Web-администраторы должны просматривать такого рода информацию, чтобы быть уверенными, что они в курсе всего, касающегося безопасности.

Директория, в которой размещено активное содержимое на web-сервере, является критичной. Если программы расположены неправильно или директория имеет неправильные разрешения доступа, это может быстро привести к компрометации web-сервера. Чтобы избежать этого, следует выполнять следующие правила.
^ Список действий для обеспечения безопасности web-содержимого
Гарантировать, что никакая из следующих типов информации не доступна через публичный web-сервер.

Установить документированную формальную политику и процесс принятия решения об опубликовании web-содержимого.

Обсудить возможность использования частной информации пользователей.

Обсуждение безопасности активного содержимого на стороне клиента.

Обсуждение безопасности активного содержимого на стороне сервера.

^ 11. Лекция: Технологии аутентификации и шифрования

Рассматриваются существующие технологии аутентификации и шифрования в web: BASIC-аутентификация, DIGEST-аутентификация, TLS/SSL-аутентификация. Изучается firewall прикладного уровня для web – ModSecurity: понятие регулярных выражений, основные возможности конфигурирования, способы задания правил (rules), действий (actions). Приводится примерная минимальная конфигурация

Публичные web-серверы часто поддерживают широкий диапазон технологий для идентификации и аутентификации пользователей с различными привилегиями для доступа к информации. Некоторые из этих технологий основаны на криптографических функциях, которые обеспечивают зашифрованный канал между web-браузером клиента и web-сервером.

Без аутентификации пользователя не существует возможности ограничить доступ пользователей к конкретной информации. Вся информация, которая расположена на публичном web-сервере, будет при этом доступна любому, кто получил доступ на сервер. Дополнительно, без некоторого процесса аутентификации сервера, пользователи не имеют возможности определить, что web-сервер аутентичен и не выполняется поддельная версия.

Шифрование может быть использовано для защиты информации, передаваемой по соединению между браузером клиента и web-сервером. Без шифрования любой, имеющий доступ к сетевому трафику, может определить и, возможно, изменить содержимое чувствительной информации, даже если пользователь при получении доступа к информации будет тщательно аутентифицирован. Это может нарушить конфиденциальность и целостность критичной информации.
^ Требования к аутентификации и шифрованию
Следует периодически проверять всю информацию, доступную на публичном web-сервере, и определять необходимые требования безопасности. При выполнении этого организация должна идентифицировать информацию, которая имеет одни и те же требования безопасности и защиты. Для чувствительной информации организация должна определить пользователей или группы пользователей, которые могут иметь доступ к каждому множеству ресурсов.

Для информации, которая требует определенный уровень аутентификации пользователя, организация должна определить, какие технологии и методы будут обеспечивать соответствующий уровень аутентификации и шифрования. Каждый из них имеет свои преимущества и свою цену, что должно быть тщательно проанализировано в соответствии с требованиями и политикой. Может оказаться предпочтительным использовать комбинацию некоторых методов аутентификации.
^ Аутентификация, основанная на IP-адресе
Простейшим механизмом аутентификации, который поддерживается большинством web-серверов, является аутентификация по IP-адресу. Управление доступом основано на IP-адресе и/или имени хоста. Хотя это легко реализовать для небольших групп пользователей, аутентификация на основе адреса может быть громоздкой для web-сайтов, которые имеют большое число потенциальных пользователей (т.е. большинство публичных web-серверов). Такая аутентификация чувствительна к некоторым типам атак, включая подделку IP-адреса (IP-spoofing) и атаки на DNS. Данный тип аутентификации должен применяться только тогда, когда требуется минимальная безопасность, в противном случае она должна использоваться совместно с более сильными методами аутентификации.
Basic-аутентификация
Технология Basic-аутентификации использует определенную структуру директорий содержимого web-сервера. Все файлы в некоторой директории должны иметь одни и те же привилегии доступа. Пользователь, выполняющий запрос, предоставляет свою идентификацию и пароль для доступа к файлам в данной директории. Каждый производитель ПО web-сервера определяет свой собственный синтаксис для использования механизма Basic-аутентификации.

С точки зрения безопасности, основной недостаток данной технологии состоит в том, что пароль передается в явном виде без шифрования. Любой, кто имеет доступ к сетевому трафику, может извлечь пароль при сетевом просматривании. Более того, все web-содержимое передается в незашифрованном виде и, тем самым, также может быть перехвачено, что нарушает конфиденциальность. Этот недостаток может быть ликвидирован с использованием Basic-аутентификации совместно с SSL/TLS. Basic-аутентификация поддерживается стандартными web-браузерами. Она используется также для защиты информации от вредоносных bots.
Digest-аутентификация
Так как в ^ Basic-аутентификации существуют определенные недостатки, в версии 1.1 протокола НТТР была введена Digest-аутентификация. Она использует для "опознания" пользователя механизм запроса / ответа (challenge / response), когда пользователю посылается nonce (случайное значение), который предназначен для использования вместе с ID и паролем. В данном случае информация, вводимая пользователем, соединяется вместе с переданным nonce и запрошенным URL, и вычисляется криптографический хэш, который затем посылается в качестве ответа.

Так как пароль пользователя не посылается в явном виде, он не может быть подсмотрен в сети. Nonce может быть сконструирован из информации о текущей дате и времени, поэтому replay-атаки также невозможны. Следовательно, Digest-аутентификация является более безопасной, чем Basic-аутентификация. К сожалению, все данные посылаются в явном виде (не шифруются), что является уязвимым для перехвата и изменения. Это ограничение можно обойти, используя Digest-аутентификацию вместе с SSL/TLS. Подобно Basic-аутентификации, Digest-аутентификация используется для защиты информации от вредоносных bots.
SSL/TLS
Протоколы SSL и TLS обеспечивают аутентификацию сервера и клиента и шифрование соединений. SSL был впервые введен компанией Netscape Communication в 1994 году и дважды пересматривался (последней версией SSL является версия 3). В 1996 году IETF основало рабочую группу TLS, чтобы определить протокол SSL в качестве стандарта Интернета. Протокол TLS версии 1.0 специфицирован в RFC 2246 в 1999 году и основывается на SSL версии 3. Можно считать, что SSL версии 3 и TLS версии 1 идентичны, поэтому они будут обсуждаться вместе. Протоколы TCP/IP управляют транспортом и роутингом данных в Интернете. Протоколы прикладного уровня, такие как НТТР, LDAP, IMAP, выполняются поверх TCP. SSL/TLS расположен между протоколом ТСР и протоколами прикладного уровня.
^ Возможности SSL/TLS
SSL/TLS обеспечивает следующие возможности.
^ Слабые места SSL/TLS
SSL/TLS присущи некоторые ограничения. Пакеты шифруются выше уровня ТСР, таким образом, информация на уровне IP не зашифрована. Хотя это и защищает передаваемые web-данные, при просмотре соединений SSL/TLS сессии можно определить как отправителя, так и получателя с помощью незашифрованной информации IP-адреса. Кроме того, SSL/TLS защищает только передаваемые данные. Он не шифрует данные, хранимые на конечных точках. Таким образом, при хранении данные становятся уязвимыми (например, база данных кредитных карт), если не предприняты дополнительные гарантии на конечных точках.

SSL/TLS также уязвим для атаки "man-in-the-middle" при отсутствии аутентификации сервера или использовании им самоподписанного сертификата. В случае анонимного сервера общий секрет вырабатывается по алгоритму Диффи-Хеллмана, который уязвим для атак "man-in-the-middle". Аналогичная ситуация возникает, когда пользователь принимает сертификат сервера без проверки его действительности вручную или при отсутствии в браузере открытого ключа выпустившего сертификат СА.

При этом атакующий устанавливает одно множество ключей сессии для использования с настоящим сервером, и другое множество ключей – для использования с клиентом. Это позволяет атакующему не только читать все данные, которые передаются между клиентом и сервером, но и изменять данные без обнаружения этого. Следовательно, очень важно для пользователей понимать опасность данного типа атаки и проверять действительность сертификата, прежде, чем полагаться на безопасность SSL/TLS сессии. Данная угроза может быть понижена, если клиент доверяет сертификатам, выпущенным доверенными CAs, или самоподписанные сертификаты получены с использованием некоторых внешних механизмов. Предоставление самоподписанного сертификата может означать, что происходит атака "man-in-the-middle". Последние версии браузеров выполняют некоторые проверки автоматически, но на это нельзя полагаться во всех случаях.
^ Пример SSL/TLS-сессии
В протоколах SSL/TLS используются симметричное шифрование и криптография с открытым ключом. Симметричное шифрование быстрее, чем шифрование с открытым ключом, в то время как криптография с открытым ключом больше подходит для обеспечения аутентификации и установлении симметричных ключей. SSL/TLS сессия всегда начинается с обмена сообщениями, называемого Рукопожатием. Рукопожатие позволяет серверу аутентифицировать себя клиенту, используя криптографию с открытым ключом; это дает возможность клиенту и серверу выработать симметричные ключи. В качестве необязательной опции при Рукопожатии можно запросить аутентификацию клиента на сервере.

Основные шаги можно просуммировать следующим образом:

  1. Клиент посылает номер версии, наборы криптографических алгоритмов, случайное число и другую информацию, необходимую серверу для взаимодействия с клиентом, используя SSL/TLS.

  2. Сервер посылает клиенту номер версии, выбранные криптографические алгоритмы, случайное число и другую информацию, необходимую клиенту для взаимодействия с сервером, используя SSL/TLS. Сервер также посылает свой собственный сертификат и, если клиент запрашивает ресурсы сервера, которые требуют аутентификации клиента, может запросить сертификат клиента.

  3. Клиент использует информацию, полученную от сервера, для аутентификации сервера. Если сервер не может быть аутентифицирован, то пользователю сообщают о проблемах и информируют, что аутентифицированное и зашифрованное соединение не может быть установлено. Если сервер успешно прошел аутентификацию, то клиент переходит к шагу 4.

  4. Используя данные, созданные на предыдущих шагах, клиент (вместе с сервером, в зависимости от используемого асимметричного алгоритма) создает мастер-секрет, из которого вычисляются ключи сессии, необходимые для обеспечения целостности и конфиденциальности соединения.

  5. Если сервер запросил аутентификацию клиента, клиент подписывает определенные данные, которые уникальны для данного Рукопожатия и известны как клиенту, так и серверу. В этом случае клиент посылает подписанные данные и свой сертификат серверу.

  6. После этого сервер пытается аутентифицировать клиента. Если клиент не может быть аутентифицирован, то сессия прерывается.

  7. Как клиент, так и сервер используют мастер-секрет для создания ключей сессии.

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

  9. Сервер посылает сообщение клиенту, информирующее его, что дальнейшие сообщения от сервера будут зашифрованы ключом сессии. Затем он посылает отдельное зашифрованное сообщение, указывающее, что серверная часть данных Рукопожатия завершена.

  10. Теперь Рукопожатие ^ SSL/TLS завершено и начинается SSL/TLS-сессия. Клиент и сервер используют ключи сессии для шифрования и дешифрования, а также для проверки целостности посылаемых друг другу данных.
^ Схемы шифрования SSL/TLS
Протокол SSL/TLS поддерживает использование различных криптографических алгоритмов для таких операций, как аутентификация сервера и клиента и установление ключей сессии.

Выбор соответствующего алгоритма шифрования зависит от нескольких факторов. Хотя на первый взгляд может показаться, что самый сильный алгоритм шифрования должен всегда указываться первым, это не всегда верно. Самый сильный алгоритм шифрования потребляет больше ресурсов сервера и снижает скорость взаимодействия. Более того, некоторые страны поддерживают ограничения на экспорт, импорт и/или использование шифрования. Проблемы с патентами и лицензиями также могут влиять на используемые схемы шифрования. Общие факторы, которые влияют на выбор алгоритма шифрования, следующие.
^ Требования к реализации SSL/TLS
Цифровые подписи необходимы для выполнения протокола SSL/TLS. Сертификаты могут быть выпущены третьей доверенной стороной (СА) или быть самоподписанными. Организационные требования определяют используемый подход.

Должны быть рассмотрены три ограничения на самоподписанные сертификаты.

После того как сертификат получен от СА или самовыпущен, необходимо сконфигурировать ^ SSL/TLS. Некоторые шаги, которые являются общими для всех web-серверов:
^ Список действий для технологий аутентификации и шифрования
Технологии web-аутентификации и шифрования.

Конфигурирование SSL/TLS.

5447921319483833.html
5448015237123061.html
5448212324377234.html
5448235692180354.html
5448404968270905.html