Безопасность приложений ASP.NET

Общие вопросы безопасности веб-приложений и виды угроз

Веб-приложения как правило работают в глобальной сети Интернет. Это означает, что потенциально к этому приложению имеет доступ любой человек, подключенный к сети Интернет. Как известно, среди пользователей могут встречаться злоумышленники, которые могут иметь намерение деструктивно воздействовать на приложение. При этом существует определенный набор угроз, которым может быть подвержено веб-приложение. Злоумышленники могут иметь различные предпосылки для взлома веб-приложения. В некоторых ситуациях злоумышленник может попытаться вывеси приложение из строя, в другом случае – получить доступ к конфиденциальным данным, и т.д. Так или иначе всегда следует помнить о возможных "узких местах" приложения и немедленно исправлять недостатки.

К основным, наиболее популярным видам угроз относятся:

• отказ в обслуживании (DoS);
• перехват конфиденциальной информации;
• неправомочный доступ к конфиденциальной информации;
• неправомочная модификация информации в приложении;
• подмена данных.

Существует еще ряд угроз, однако они менее критичны, чем перечисленные выше угрозы.

DoS-атака (denial of service, отказ в обслуживании) – это вид атаки на приложение, при котором генерирует большое число одновременных запросов к приложению. Цель этой атаки вывести приложение из работоспособного состояния (или существенно снизить производительность).

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

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

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

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

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

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

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

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

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

Для защиты от подобных атак следует использовать рекомендации, приведенные для защиты от предыдущего вида атак.

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

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

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

Как видно, существует большое количество угроз. Поэтому при разработке веб-приложений всегда следует помнить в потенциальной возможности атаки приложения и строить приложение в соответствии с требованиями безопасности.

Краткие итоги

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

Модель безопасности ASP.NET

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

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

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

Аутентификация в приложениях на базе ASP.NET может осуществляться следующими способами:

• аутентификация формами;
• аутентификация Windows;
• аутентификация с помощью паспортов;
• специализированным механизмом аутентификации.

Самым простым способом аутентификации является аутентификация формами. При таком подходе пользователь должен ввести имя пользователя и пароль на странице ASP.NET.

Аутентификация Windows позволяет определить пользователя на основе корпоративной политики. Например, в качестве хранилища информации о пользователях может быть Active Directory.

Аутентификация с помощью паспортов предусматривает наличие третьей стороны, которая гарантирует, что пользователь является именно тем, за кого он себя выдает. Примером подобной аутентификации является служба Live ID и Open ID.

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

Для того чтобы использовать встроенный механизм аутентификации формами, необходимо его настроить. Для этого используется файл "web.config". Конфигурационный файл содержит секцию "authentication", которая содержит всю необходимую информацию.

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

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

В этом примере атрибут "passwordFormat" секции "credentials" определяет способ хранения пароля. Значение "clear" указывает на то, что пароль хранится в открытом виде. Кроме этого, пароль можно хранить в виде хэша MD5 или SHA1.

После задания всех настроек можно воспользоваться механизмом аутентификации формами. Для этого необходимо воспользоваться классом FormsAuthentication и его статическими методами Authenticate, SignOut, RedirectFromLoginPage и RedirectToLoginPage. Таким образом, программный код для выполнения входа в систему может выглядеть следующим образом.

Теперь, на каждой странице становится возможным проверить выполнен ли вход в систему и, если выполнен, то кем. Для этого можно воспользоваться свойствами IsAuthenticated и Name объекта IIdentity, доступ к которому можно получить, используя текущий контекст - HttpContext.Current.User.Identity.

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

Именно поэтому в ASP.NET существует механизм Membership API. По сути, Membership API – это интерфейс, который позволяет:

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

Таким образом, Membership API – это интерфейс для реализации различных поставщиков для хранения информации о пользователях. Такое абстрагирование на уровне интерфейса позволяет быть независимым от конкретной реализации поставщика и одинаково работать, например, с поставщиком на основе базы данных или Active Directory. ASP.NET включает ряд готовых поставщиков для SQL Server и Active Directory. Это позволяет хранить данные о пользователях и ролях в SQL Server или в Active Directory. Кроме того, можно разработать собственный поставщик, который в качестве хранилища будет использовать другой источник (например, файл на жестком диске). Для этого необходимо создать класс-наследник MembershipProvider из пространства имен "System.Web.Security" и указать его в конфигурационном файле.

Для того, чтобы использовать Membership API в своих приложениях необходимо выполнить несколько шагов:

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

Наиболее часто в качестве хранилища данных используется база данных на основе SQL Server. Для SQL Server разработана готовая схема данных, которая позволяет хранить пользователей, пароли, роли и т.д. Для того чтобы создать подобную схему данных в вашей БД необходимо воспользоваться утилитой aspnet_regsql, которая расположена в папке "C:\Windows\Microsoft.NET\Framework\v2.0.50727". Эта утилита поддерживает два режима работы – консольный и графический. Для запуска утилиты в консольном режиме необходимо указать параметры:

В этой команде указывается имя сервера "(local)" и имя базы данных "MyDB". Кроме того, можно запустить эту утилиту без параметров, тогда она будет работать в графическом режиме. В этом случае необходимо указать мастеру нужные параметры, после чего будет создана нужная схема данных.

Для создания указанной схемы данных необязательно пользоваться утилитой aspnet_regsql. В папке "C:\Windows\Microsoft.NET\Framework\v2.0.50727" расположены скрипты для SQL Server, которые позволяют создать или удалить эту схему данных. Поэтому для создания базы данных можно вручную запустить эти SQL-скрипты. Список файлов для создания и удаления схемы:

• InstallCommon.sql
• InstallMembership.sql
• InstallPersistSqlState.sql
• InstallPersonalization.sql
• InstallProfile.SQL
• InstallRoles.sql
• InstallSqlState.sql
• InstallSqlStateTemplate.sql
• InstallWebEventSqlProvider.sql
• UninstallCommon.sql
• UninstallMembership.sql
• UninstallPersistSqlState.sql
• UninstallPersonalization.sql
• UnInstallProfile.SQL
• UninstallRoles.sql
• UninstallSqlState.sql
• UninstallSqlStateTemplate.sql
• UninstallWebEventSqlProvider.sql

После создания схемы данных необходимо сконфигурировать провайдер Membership API. Для этого в секции "system.web" необходимо создать секцию "membership", внутри которой указать нужных провайдеров. Кроме того, в атрибуте "defaultProvider" секции "membership" необходимо задать имя текущего провайдера. Таким образом, конфигурационный файл может выглядеть следующим образом.

Как видно, при добавлении нового поставщика задается его имя, тип и строка соединения с базой данных, которая задается в секции "connectionStrings".

После этого Membership API готов к работе. Для создания новых пользователей и удаления старых, можно воспользоваться статическими методами CreateUser и DeleteUser класса Membership

После выполнения аутентификации следует процесс авторизации. Сам процесс авторизации может поддерживаться на двух уровнях:

• можно определить пользователей, которые имеют доступ к ресурсам на уровне каталога. Таким образом, можно предоставить доступ к ресурсам каталога только определенному кругу пользователей;
• в модели безопасности ASP.NET поддерживаются роли. Роль – это группа пользователей, в которой контроль доступа осуществляется для всех пользователей, входящих в эту группу. Например, при отображении страницы можно проверить входит ли пользователь в заданную роль, и, если пользователь в нее входит, то отобразить конфиденциальную информацию; в противном случае – вывести сообщение об ошибке.

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

Краткие итоги

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