Построение защищенных Web-приложений на основе IIS и MS SQL Server

Чтобы настроить ASP.NET для олицетворения  идентификации Windows, предлагаемой IIS, как WindowsIdentity для приложения ASP.NET, следует отредактировать файл Web.config этого приложения и установить для атрибута impersonate элемента конфигурации identity значение true, как показано в следующем примере.

 

<configuration>

  <system.web>

    <identity impersonate="true" />

  </system.web>

</configuration>

 

Олицетворение не зависит от режима mode проверки подлинности, настроенного с помощью элемента конфигурации Проверка подлинности. Этот элемент проверки подлинности используется для определения свойства User текущего контекста HttpContext. Олицетворение используется для определения идентификации WindowsIdentity приложения ASP.NET.

В качестве примера далее описывается  способ разрешения олицетворения с  помощью сценария интрасети. В этом сценарии внутренний корпоративный  веб-узел настраивается для отправки сведений сотрудникам. Предполагается однако, что некоторая информация предназначена только для менеджеров. Информация для менеджеров может быть отправлена во вложенную папку информационного узла для сотрудников так, чтобы можно было ограничить к ней доступ. IIS определяет удостоверение пользователя с помощью встроенной службы безопасности Windows (NTLM). В сценарии предполагается:

• на веб-узле установлена операционная система Microsoft Windows Server 2008 R2;
• на веб-сервере установлены службы IIS 7;
• жесткий диск веб-сервера отформатирован с помощью NTFS;
• все сотрудники, которым нужно предоставить доступ к ограниченному ресурсу, используют Windows.

Администратор приложения в этом сценарии должен выполнить следующие действия:

1. cоздать файлы и каталоги, как показано на рисунке 18;

 

Рисунок 18 – Дерево каталогов

 

2. создать группу Windows с именем «Менеджеры» и включить в нее всех пользователей, которые должны иметь доступ к файлу ManagerInfo.aspx;
3. с помощью диспетчера IIS отключить в этом приложении анонимную проверку подлинности и включить встроенную проверку подлинности Windows;
4. в файле Web.config приложения установить для атрибута impersonate в элементе идентификация значение true;
5. установить список управления доступом NTFS для каталога ManagerInformation таким образом, чтобы доступ был разрешен только тем удостоверениям пользователей, которые перечислены в группе «Менеджеры» в Windows, и всем нужным системным учетным записям. Необходимо будет проверить, что идентификация процесса ASP.NET включена. Идентификация процесса ASP.NET для Windows 2000 Server или Windows NT представляет собой локальную учетную запись ASP.NET. Идентификация процесса ASP.NET для Windows Server 2003 и последующих версий представляет собой идентификацию пула приложений IIS, которая по умолчанию является учетной записью NETWORK SERVICE.

 

 

 

 

1.5 Настройка SSL на IIS 7

 

 

Общие действия по конфигурированию SSL на IIS 7:

• получить соответствующий сертификат;
• создать привязку HTTPS на сайте;
• провести тест, сделав запрос к сайту;
• опционально задать дополнительные настройки SSL, например, сделав использование SSL обязательным требованием;

Реализация SSL в IIS 7 изменилась, по сравнению  с IIS 6.0. На Windows Server 2003 вся конфигурация SSL хранилась в метабазе IIS и процессы шифрования/дешифрования проходили в пользовательском режиме (требовалось множество переходов между режимами ядра/пользователя). На Windows Vista и Windows Server 2008 HTTP.sys обрабатывает шифрование/дешифрование SSL в режиме ядра, что увеличивает производительность защищенных соединений до 20 процентов.

Перенос SSL в режим ядра требует  сохранения информации о привязке SSL в двух местах. Во-первых, привязка хранится в %windir%\system32\inetsrv\applicationHost.config для сайта. Когда сайт запускается, IIS 7 отправляет привязку к HTTP.sys и HTTP.sys начинает прослушивать запросы на указанной паре IP:Port(это работает для всех привязок). Во-вторых, конфигурация SSL, связанная с привязкой, хранится в конфигурации HTTP.sys. Чтобы увидеть конфигурацию привязки SSL, сохраненную в файле HTTP.sys, необходимо использовать команду netsh:

netsh http show sslcert

Когда клиент подключается и начинает согласование SSL, HTTP.sys просматривает свою конфигурацию SSL для пары IP:Port, к которой подключен клиент. Конфигурация SSL HTTP.sys должна включать в себя хэш сертификата и имя хранилища сертификата для того, чтобы согласование SSL прошло успешно.

Чтобы конечные пользователи могли  проверить удостоверение сервера  с помощью сертификата, необходимо либо создать запрос сертификата и отправить этот запрос в известный центр сертификации, например, VeriSign или GeoTrust, либо получить сертификат от онлайнового центра сертификации в вашем домене интрасети. Есть три вещи, которые браузер обычно делает при проверке сертификата сервера:

1. Сравнивает текущую дату/время с датами «Действителен от» и «Действителен до» сертификата.
2. Сопоставляет общее имя (Common Name, CN) сертификата c заголовком хоста в запросе.
3. Проверяет, чтобы поставщиком сертификата был известный и доверенный центр сертификации.

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

Самозаверяющие сертификаты – это сертификаты, созданные собственным компьютером. Они полезны в рабочей среде, в которой для конечного пользователя не обязательно доверять серверу, например, тестовая рабочая среда.

Рассмотрим получение сертификата  с помощью IIS Manager.

Необходимо выбрать узел сервера  в представлении в виде дерева. Затем нужно выбрать функцию  «Сертификаты сервера» (рисунок 19).

 

Рисунок 19 – Функция «Сертификаты сервера»

 

На панели Действия нужно кликнуть на Создать самозаверенный сертификат… Далее нужно вести имя создаваемого сертификата. Выполнение показано на рисунке 20.

 

Рисунок 20 – Создание самозаверенного сертификата

Таким образом был создан самозаверяющий сертификат, представленный на рисунке 21. Этот сертификат отмечен для использования «Сертификаты сервера», т.е. использования в роли серверного сертификата для шифрования SSL HTTP и для аутентификации удостоверений сервера.

 

Рисунок 21 – Самозаверяющий сертификат

 

Для создание привязки SSL нужно выбрать сайт в представлении в виде дерева и щелкнуть Привязки… на панели Действия. Появится редактор привязки, который позволяет создавать, редактировать или удалять привязки для веб-сайта. Нужно нажать на кнопку Добавить..., чтобы добавить новую привязку к сайту (Рисунок 22).

 

Рисунок 22 – Создание привязки SSL

 

Новая привязка по умолчанию установлена  для http на порт 80. В выпадающем списке Тип нужно выбрать https. Из выпадающего списка Сертификаты SSL нужно выбрать созданный ранее самозаверяющий (рисунок 23).

 

Рисунок 23 – Добавление привязки сайта

Таким образом была создана новая привязка SSL для сайта (рисунок 24) и все, что остается, это проверить ее работу.

 

Рисунок 24 – Привязка SSL для сайта

 

Нужно найти на панели Действия сайта ссылку, которая ведет на сайт через новую привязку HTTPS и нажать на эту ссылку, чтобы протестировать новую привязку. Результат показан на рисунке 25.

 

Рисунок 25 – Тестирование новой привязки

 

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

Чтобы сконфигурировать настройки SSL, нужно щелкнуть на узле сайта в представлении в виде дерева для возврата к домашней странице сайта и выбрать функцию Параметры SSL на центральной панели. Окно параметров SSL показано на рисунке 26.

 

Рисунок 26 – Параметры SSL

 

 

 

 

1.6 Атаки на IIS

 

 

1.6.1 Уязвимость при обработке Telnet IAC символов в Microsoft IIS FTP Server

 

 

Уязвимость позволяет удаленному пользователю вызвать отказ в  обслуживании и выполнить произвольный код на целевой системе.

Уязвимость существует из-за ошибки проверки границ данных в процессе шифрования Telnet IAC символов в FTP запросе (в особенности символа 0xFF). Удаленный не аутентифицированный пользователь может с помощью специально сформированного FTP запроса вызвать переполнение динамической памяти и выполнить произвольный код на целевой системе.

Уязвимости подвержены все версии Microsoft Internet Information Services (IIS) 7.x.

В настоящее время существует решение  данной проблемы. Необходимо установить соответствующее обновление. Либо, можно отключить службу FTP, если она не используется.

 

 

 

 

1.6.2 Уязвимость, обнаруженная сотрудниками Secunia

 

 

Проприетарный набор серверов для нескольких интернет-служб Microsoft Internet Information Services(IIS) содержит уязвимость, позволяющую дистанционно выполнять вредоносный код, утверждают эксперты Secunia.

Уязвимость затрагивает систему  обработки имен файлов и расширений в веб-сервере, который является основным компонентом Microsoft IIS.

Обычно веб-приложения сконфигурированы таким образом, чтобы отвергать попытки загрузки исполнимых файлов, снабженных, например, расширениями .asa, .asp, .aspx или .cer. Между тем выяснилось, что добавление к оригинальному наименованию файла доверенного расширения (через точку с запятой) позволяет обойти ограничения, заставив систему считать, что файл с именем file.aspx;.jpg содержит лишь безопасную графическую информацию.

Однако обрабатываться такой файл будет как исполнимый.

По мнению специалистов Secunia, уязвимость встречается во всех версияx IIS. С точки зрения уровня критичности уязвимость была оценена на два балла из пяти возможных, хотя наблюдатели не согласны со столь низкой оценкой.

Уязвимость была исправлена соответствующим  пакетом обновления безопасности.

 

 

 

 

1.6.3 Уязвимость WebDAV

 

 

В серверном программном обеспечении Microsoft Internet Information Services 6 была обнаружена уязвимость, которая может поставить под угрозу сохранность их данных.

Утечка вскрылась, когда исследователь  Николаус Рангос опубликовал подробности о ней в рассылке Full Disclosure. Послав серверу особым образом составленный HTTP-запрос, он получил возможность просматривать и загружать на него различные файлы. Баг скрывается в способе обработки сервером IIS6 токенов, использующих кодировку Unicode.

Организация US CERT сообщила о наличии  случаев онлайн-атак на эту уязвимость. Баг актуален для тех пользователей IIS 6, у которых включены протоколы  WebDAV, служащие для обмена документами через Сеть.

Независимый исследователь Тьерри Золлер подтвердил правильность изысканий Рангоса. Он сообщил, что эта уязвимость дает хакерам возможность просматривать и загружать файлы без авторизации. При этом способа запустить на сервере IIS неавторизованное ПО ему обнаружить не удалось. Золлер сообщил, что версии IIS 5 и IIS 7 данной уязвимости не подвержены, добавив при этом, что она может сработать с другими приложениями Microsoft, использующими технологию WebDAV.

В настоящее время проблема решена. Для ее устранения необходимо установить патч.

 

 

 

1.6.4 Атаки по раскрытию исходного кода

 

 

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

Уязвимые места, которые позволяют  просмотреть исходный код, возникают по двум причинам:

• ошибки в сервере IIS;
• некачественное Web-программирование.

Сервер ITS имеет "богатую историю" ошибок, которые позволяют просматривать исходный код файлов сценариев или другие засекреченные данные (::$DATAS, showcode. asp). Ситуация во многом усложняется благодаря Web-разработчикам, которые в исходных кодах своих ASP-сценариев или в файлах global. asa жестко кодируют важную информацию. Классический пример — сохранение пароля учетной записи в строке соединения с базой данных SQL в ASP-сценарии, который обеспечивает доступ к базе данных. Проблемы только усилились с ростом популярности Web-служб и новых свойств конфигурации сервера IIS 6.

Большинство Web-разработчиков полагают, что такая информация никогда не будет видна на клиентской стороне, поскольку сервер IIS по-разному работает с файлами в зависимости от их расширений. Например, файлы с расширением .htm просто возвращаются в браузер клиента, а сценарии . asp перенаправляются механизму обработки и выполняются на стороне сервера. Только данные из результатов выполнения этой обработки должны передаваться в браузер клиента. Таким образом, исходный код ASP никогда не попадет клиенту.