Безопасность веб-приложений во время выполнения

Статья
10/22/2014

Обновлен: Ноябрь 2007

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

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

Защитить собственные ресурсы разработчика от несанкционированного доступа.
Ограничить уровни доступа по пользователям или ролям.
Обеспечить целостность и секретность данных путем формирования относительно безопасной среды, в которой пользователям будет удобно работать с приложением.
Установить контроль над доступом приложения к ресурсам ограниченного пользования.
Обеспечить выполнение кода приложения в требуемом режиме.

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

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

Средства безопасности IIS как часть общего набора функций веб-сервера IIS. Эти средства включают поддержку безопасности на уровне пользователей, компьютеров и файлов Windows.
Средства безопасности, которые можно встраивать в приложения ASP.NET для обеспечения доступа к определенному приложению.

Механизм безопасности в ASP.NET

Службы IIS предоставляют множество параметров безопасности для веб-узлов. Однако механизмы безопасности IIS являются слишком универсальными: одни и те же методы используются для всех приложений. Кроме того, функции безопасности IIS (например, встроенная безопасность Windows) могут не всегда быть удобны для использования в приложении. (С другой стороны, в приложениях интрасети разработчики могут для простоты использовать именно метод встроенной безопасности Windows.)

Поэтому для большей детализации доступа к определенной части приложения можно использовать средства безопасности ASP.NET. Подсистема безопасности ASP.NET действует совместно со средствами безопасности IIS и при этом расширяет их, позволяя настроить такие возможности, как способ получения учетных данных пользователя.

IIS сначала получает запросы от клиентов и выполняет все проверки безопасности, которые были определены для приложения с помощью инструментов управления IIS. Например, если в IIS был разрешен анонимный доступ к приложению, то IIS не выполняет проверку учетных данных. После выполнения начальной проверки подлинности IIS передает запрос в ASP.NET, где производятся проверки второго уровня. ASP.NET позволяет задавать ограничения доступа в приложении с помощью различных критериев: можно ограничить доступ к конкретным страницам, для конкретных пользователей и т. д.

Проверка подлинности

В следующей таблице приведены методы проверки подлинности, поддерживаемые ASP.NET. Некоторые из них перекрываются с методами проверки подлинности IIS. Дополнительные сведения см. в разделе Проверка подлинности ASP.NET.

Тип проверки подлинности	Описание
Анонимный доступ	Для приложений, в которых запросы будут делать неизвестные пользователи (обычно это общедоступные веб-приложения). Перекрывается с IIS.
Обычная и краткая проверка подлинности	(Функции безопасности IIS.) Пользователям, не имеющим учетных данных, предлагается ввести имя пользователя и пароль.
Встроенная безопасность Windows (известная также как безопасность NTLM)	(Функции безопасности IIS) Если пользователь, пославший запрос, уже проходил проверку подлинности в сети Windows, IIS может передать на сервер учетные данные пользователя при обращении к ресурсу.
Проверка подлинности с помощью сертификатов	(Функции безопасности IIS) У сервера или клиента должен иметься сертификат (цифровой код), полученный из стороннего источника. Идентификация, сопоставленная с сертификатом клиента, передается ASP.NET.
Kerberos	(Функция безопасности IIS) Протокол проверки подлинности Kerberos определяет правила взаимодействия клиента с сетевой службой проверки подлинности под названием KDC (центр распределения ключей). Она реализована в Windows 2000 и 2003 в качестве службы проверки подлинности на каждом контроллере домена.
Проверка подлинности Windows	(Функция безопасности ASP.NET) Интегрируется с предыдущими перечисленными функциями безопасности IIS. ASP.NET берет маркер безопасности, созданный службами IIS, и делает его доступным как объект WindowsPrincipal, устанавливаемый как значение свойства User текущего HttpContext.
Проверка подлинности с помощью форм	(Функция безопасности ASP.NET) Если пользователь должен пройти проверку подлинности, ASP.NET перенаправляет запрос на заданную разработчиком страницу. Эта страница обычно содержит форму, в которой пользователь вводит свои учетные данные. (Для усиления безопасности обмен данными с формой можно вести по протоколу HTTPS.) Получив информацию из формы, приложение может выполнить заданную проверку учетных данных пользователя. Важное значение имеет то, что этот процесс контролируется разработчиком (в отличие от проверки в IIS), который имеет возможность задать внешний вид формы и способ хранения данных пользователя. Если пользователь успешно проходит проверку подлинности, ASP.NET создает зашифрованный объект cookie, который содержит маркер, служащий идентификатором пользователя при последующем доступе.

Проверка подлинности с помощью форм обычно является наилучшим вариантом для приложений ASP.NET, потому что она предоставляет более широкие возможности контроля проверки подлинности пользователей, а также позволяет сохранять результаты проверки в маркере обозревателя.

Сведения о безопасности IIS см. в разделах об управлении доступом центра Windows Server TechCenter for IIS на веб-узле Microsoft TechNet. Дополнительные сведения о проверке подлинности в ASP.NET см. в разделе Проверка подлинности ASP.NET.

Сведения об использовании проверки подлинности при помощи форм с переходом протоколов и ограниченным делегированием в среде домена Windows Server 2003 см. раздел Kerberos Protocol Transition and Constrained Delegation (на английском языке).

Авторизация

Во время выполнения веб-приложение запрашивает ресурсы веб-сервера и других процессов, например базы данных. Процесс ASP.NET выполняется в пользовательском контексте, который определяет, как приложение будет запрашивать эти ресурсы. Процесс ASP.NET действует как специальный локальный пользователь с именем ASPNET (по умолчанию) в Windows 2000 и Windows XP Professional Edition или же действует как учетная запись для пула приложений ASP.NET в Windows 2003 (по умолчанию, локальная учетная запись NETWORK SERVICE). Эти учетные записи действуют с ограниченными разрешениями. Для процесса ASP.NET можно задать другой пользовательский контекст, включая локальную учетную запись SYSTEM (контекст администратора) или контекст пользователя, учетные данные которого предоставляются явным образом, хотя это не рекомендуется.

В приложении ASP.NET можно указать, что разным пользователям будет предоставляться авторизованный доступ к различным ресурсам. Если в приложении используется проверка подлинности Windows, можно использовать разрешения Windows для определения возможности доступа к конкретным файлам или папкам сервера.

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

Имен конкретных пользователей, или удостоверений, создаваемых на основе учетных данных, которые предоставляются пользователем.
Ролей, с помощью которых нескольким пользователям можно назначать общие привилегии для выполнения определенных функций.
Действий — процессов HTTP, используемых для доступа к различным частям приложения (например, GET и POST).

Например, можно настроить авторизацию так, чтобы все пользователи могли получать страницы из приложения (с помощью операции GET), но только определенные пользователи могли отправлять страницы в это приложение (POST). Аналогичным образом можно разрешить всем пользователям получать страницы, запретив при этом некоторым ролям отправлять страницы.

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

Примечание.
По умолчанию статические файлы, такие как изображения и таблицы стилей, не подлежат проверке подлинности ASP.NET при использовании службами IIS. Средства обеспечения безопасности служб IIS можно использовать для ограничения доступа к статическим файлам, если вы не хотите, чтобы все пользователи имели к ним доступ. Если для тестирования приложения ASP.NET используется сервер ASP.NET Development Server, то будет очевидна разница в поведении, поскольку статические файлы подлежат проверке подлинности ASP.NET и не будут использоваться анонимным пользователем, поскольку анонимный доступ к этим файлам отключен. Также можно сопоставить расширения имен файлов в службах IIS с расширением ASP.NET ISAPI, в этом случае будут действовать правила авторизации ASP.NET.

По умолчанию статические файлы, такие как изображения и таблицы стилей, не подлежат проверке подлинности ASP.NET при использовании службами IIS. Средства обеспечения безопасности служб IIS можно использовать для ограничения доступа к статическим файлам, если вы не хотите, чтобы все пользователи имели к ним доступ. Если для тестирования приложения ASP.NET используется сервер ASP.NET Development Server, то будет очевидна разница в поведении, поскольку статические файлы подлежат проверке подлинности ASP.NET и не будут использоваться анонимным пользователем, поскольку анонимный доступ к этим файлам отключен. Также можно сопоставить расширения имен файлов в службах IIS с расширением ASP.NET ISAPI, в этом случае будут действовать правила авторизации ASP.NET.

Дополнительную информацию см. в ASP.NET Authorization и Основные методы обеспечения безопасности веб-приложений.

Файлы конфигурации ASP.NET

Параметры безопасности ASP.NET задаются в файле конфигурации Web.config. В этот файл можно добавлять предварительно определенные элементы для различных механизмов безопасности, включая авторизацию и проверку подлинности. Соответствующие разделы файла Web.config будут выглядеть примерно следующим образом.

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" />
    </authentication>
    <authorization>
      <deny user="?" />
    </authorization>
  </system.web>
</configuration>

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

Дополнительную информацию см. в ASP.NET Architecture.

Безопасность XML веб-служб

XML веб-службы, использующие файлы .asmx, выполняются так же, как и веб-приложения, использующие ASP.NET, поэтому они интегрированы в ту же модель безопасности, что и любые приложения ASP.NET. Например, XML веб-службу можно настроить для использования обычной проверки подлинности или встроенной безопасности Windows.

Во время разработки при попытке добавить ссылку на XML веб-службу (т. е. инициировать запрос документов обнаружения XML веб-службы) эта веб-служба выполнит стандартную проверку подлинности веб-приложения в соответствии с настройкой. Например, если XML веб-служба настроена на использование обычной проверки подлинности, то клиент, обращающийся с запросом, должен будет предоставить имя пользователя и пароль. Если XML веб-служба использует обычную проверку подлинности, то в диалоговом окне "Добавить веб-ссылку" будет предложено ввести учетные данные.

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

Другие средства безопасности ASP.NET могут быть недостаточно гибкими, поэтому для XML веб-служб можно реализовать специализированное решение проверки подлинности, в котором учетные данные передаются в заголовках SOAP. В таком решении учетные данные передаются в дополнительной части сообщений, которыми обмениваются клиент и сервер. Затем следует записать пользовательский HTTP-модуль (выполняя интерфейс IHttpModule), который будет прослушивать информацию в заголовке и фиксировать код проверки.

Как и другие приложения ASP.NET, XML веб-службы могут использовать авторизацию на основе ролей для ограничения доступа к некоторым частям приложения.

Подробности см. в Инфраструктура XML веб-служб и Обеспечение безопасности веб-служб XML, созданных при помощи ASP.NET.

Целостность и секретность данных

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

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

Для обмена зашифрованными данными по протоколу HTTPS можно использовать протокол Secure Sockets Layer (SSL) в службах IIS. SSL поддерживает секретность в обоих направлениях: шифруются как данные, передаваемые пользователю, так и данные, которые приложение получает от пользователя.

Использование SSL и шифрования

Для использования шифрования и SSL следует получить сертификат сервера для организации или отдельного лица. Сертификат — это цифровая подпись, которая идентифицирует веб-узел способом, исключающим возможность подделки. Для открытых Интернет-приложений сертификат сервера можно получить в официальном центре сертификации. Для закрытых приложений (в интрасети) сертификат можно выдать и получить самостоятельно. Это позволяет засекретить внутренние приложения, например веб-узел отдела кадров.

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

Примечание.
Для использования SSL требуется, чтобы обозреватель поддерживал шифрование с ключом длиной не менее 40 бит. Это возможно практически во всех обозревателях. Тем не менее, использование ключа с такой длиной не считается безопасным. При желании можно настроить приложение в службах IIS на разрешение только соединений SSL со 128-битным ключом.

Для использования SSL требуется, чтобы обозреватель поддерживал шифрование с ключом длиной не менее 40 бит. Это возможно практически во всех обозревателях. Тем не менее, использование ключа с такой длиной не считается безопасным. При желании можно настроить приложение в службах IIS на разрешение только соединений SSL со 128-битным ключом.

После получения сертификата сервера можно сообщить пользователям о том, что они должны работать с протоколом SSL, указывая префикс https:// в запросах на получение и отправку веб-страниц. Веб-узел может также быть настроен в службах IIS на принятие только соединений HTTPS. Служба IIS и обозреватель будут автоматически использовать зашифрованный канал обмена информацией.

Подробные сведения о шифровании узла с использованием протокола SSL см. в статье Q307267 "Как повысить безопасность соединения с XML веб-службами с помощью протокола SSL в Windows 2000" в базе знаний Microsoft. Информацию о шифровании см. в руководстве Общие сведения о шифровании. Сведения о сертификатах и настройке протокола SSL см. в разделах об управлении доступом центра Windows Server TechCenter for IIS на веб-узле Microsoft TechNet.

Использование безопасности кода .NET

В заключение необходимо обеспечить защиту кода приложения от некорректного использования, в том числе от случайного выполнения в неправильном контексте и от использования злоумышленниками в своих целях. Поскольку ASP.NET является частью .NET Framework, можно также использовать преимущества управления доступом для кода, чтобы определять, какой код может выполняться. Дополнительные сведения см. в разделе Управление доступом для кода.

См. также

Основные понятия

Основные методы обеспечения безопасности веб-приложений

Share via