Безопасность - tolstykh.com

Из цикла лекций «Технологии разработки Internet-приложений» для студентов 4-го курса кафедры Компьютерных
технологий физического факультета Донецкого национального университета
Технологии
разработки Internetприложений
ASP.NET приложения:
Безопасность
проф. В.К.Толстых, www.tolstykh.com
Безопасность
Безопасность — важнейшая часть Web-приложений, и она должна приниматься во
внимание с первой стадии процесса разработки.
Моделирование угроз безопасности становится все более важным в современном процессе
разработки программного обеспечения. Моделирование угроз — это структурированный
способ анализа среды ваших приложений с точки зрения возможных опасностей, их
классификации и решений относительно приемов смягчения этих угроз.
Помните, что система защиты ровно настолько надёжна,
насколько надёжна её самая слабая часть.
1. Проблемы безопасности до подключения
клиентов к сайту
•
•
•
Плохо контролируемый физический доступ к оборудованию.
Некачественное архивирование.
Наличие «инсайдеров» в обслуживающем персонале.
Необходима сегрегация обязанностей, шифрование данных на всех серверах, раздельное
хранение ключей доступа к данным. Не храните на сайте сборки в исходных кодах, делайте
предкомпиляцию в .dll-файлы.
2. Проблемы безопасности в момент
подключения клиента
•
•
•
Предусмотрите возможность DoS-атак. Помните, необходим запас производительности
сервера для эффективной борьбы с DoS-атаками. Установите минимальный приоритет
обработки ICMP-сообщений (устранение ping-флуда). Настройте ограничения run-time
(ASP.NET 4.0, см. далее)
При необходимости обеспечьте конфиденциальность. Когда пользователь работает с
приложением, вы должны гарантировать, что никто другой не сможет видеть важные данные,
которые он обрабатывает. Для этого, например:
- включайте SSL при использовании Basic-аутентификации или аутентификации
форм ASP.NET.
- применяйте SSL для всего сайта. В общем случае, если ваше Web-приложение
обрабатывает важные данные, защищайте весь Web-сайт с помощью SSL.
Не забывайте защищать даже каталоги с графическими изображениями или другими
файлами, которые не управляются приложением напрямую через SSL.
При необходимости реализуйте аутентификацию пользователя. Аутентификация задает
вопрос: кто идет? В конечном итоге она определяет, кто работает с вашим приложением на
другой стороне.
3. Проблемы безопасности после
подключения клиента
• Авторизация – определения прав и ограничений, назначенных аутентифицированному
•
пользователю. После того, как только вы узнали, кто работает с вашим приложением, ваше
приложение должно решить, какие операции данный пользователь может выполнять и к каким
ресурсам обращаться. Другими словами, авторизация отвечает на вопрос: каков ваш уровень
допуска?
Контролируйте целостность данных, никогда не размещайте важные данные:
- в скрытых полях вашей Web-страницы. Скрытые поля могут быть легко изменены
простым просмотром исходного кода Web-страницы, модификацией и сохранением
в файле. Затем злоумышленник, просто, может отправить локальную модифицированную копию Web-страницы на сервер.
- в состоянии представления, – это ещё одно скрытое поле на Web-странице и оно
может быть легко декодировано и просмотрено. Используйте свойство страницы
ViewStateUserKey для хеширования данных состояния и атрибут
EnableViewStateMAC для подписи страницы аутентификационным кодом машины,
чтобы убедиться, что состояние представления не было изменено на стороне клиента.
- в cookie. Всегда защищайте cookie с данными аутентификации при аутентификации
посредством форм и устанавливайте таймауты насколько возможно короткими,
и не длиннее, чем это действительно необходимо.
Вы должны гарантировать, что данные, передаваемые между клиентом и сервером, не
изменяются в результате неавторизованного вмешательства.
Цифровые подписи позволяют снизить уровень этой угрозы.
Правила безопасного кодирования
•
•
•
•
•
Никогда не доверяйте пользовательскому вводу. Предполагайте, что каждый
пользователь — злоумышленник, пока он не докажет обратное. Разрабатывайте свой код
проверки достоверности так, чтобы он проверял ввод только правильных значений («Белые
списки»).
Если можно, то не используйте GET-параметры, т. к., во-первых, это может создать
проблемы индексации у поисковиков, во-вторых, потребует дополнительных усилий валидации
данных, или поддержки «белых» списков GET-параметров. POST-параметры проще
контролировать стандартными валидаторами и, просто, Web-элементами управления.
Никогда не используйте конкатенацию строк для формирования операторов SQL.
Всегда применяйте параметризованные операторы, чтобы ваше приложение не было уязвимо
для атак внедрением SQL.
Никогда не выводите данные, введенные пользователем, на Web-страницу до их
проверки и кодирования. Пользователь может ввести некоторые фрагменты кода HTML
(например, сценарий), которые инициируют межсайтовую сценарную уязвимость. Поэтому
всегда используйте HttpUtility.HtmlEncode() для защиты специальных символов вроде <, >
перед выводом их на страницу или применяйте Web-элементы управления, которые
выполняют такое кодирование автоматически.
Контролируйте возможные ошибки времени выполнения. Используйте операторы try на
страницах приложения и централизованную обработку ошибок приложения в Global.asax.
Среда .NET не требует существенных дополнительных вычислительных ресурсов для
реализации такого контроля времени выполнения.
Пример ограничений run-time (.NET 4)
<configuration>
<system.web>
<httpRuntime
maxRequestLength = "4096" // – допустимый объём данных от клиента,
для предотвращения DoS-атак
MaxUrlLength ="260" // – макс. длина URL в заголовке HTTP-запроса
maxQueryStringLength="2048" // – макс. количество символов GET-запроса
enableHeaderChecking = "true" // проверять заголовки HTTP-запросов на
атаки SQL-инъекций
requestPathInvalidChars="<,>,*,%,&,:,\" // список символов
не допустимых в пути URL в HTTP-запросе
requestValidationType="CustomRequestValidation" // пользовательский класс
валидатора межсайтовых атак XSS (см. далее)
/>
Значения параметров соответствуют значениям по умолчанию.
Межсайтовые атаки XSS (Сross Site Sсriрting)
XSS — тип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой
страницу вредоносного кода (который будет выполнен на компьютере пользователя при
открытии им этой страницы) и взаимодействии этого кода с веб-сервером
злоумышленника. Является разновидностью атаки «внедрение кода».
ASP.NET проверяет строку HTTP запроса на наличие данных, которые обычно используются при
межсайтовых атаках (XSS). Если будет найдена потенциально опасная подстрока, то будет
выставлен проверочный флаг и вернется ошибка. Встроенный анализатор вернет ошибку
только в том случае, если он найдет самые общие строки, используемые при XSS
нападениях. В ASP.NET 4.0 функция проверки позволяет использовать собственные
алгоритмы анализа запросов.
В случае если вы не хотите специальным образом контролировать HTTP входные данные, вы
можете не создавать пользовательский класс, а просто воспользоваться методом
base.IsValidRequestString для запуска анализатора ASP.NET по умолчанию.
Далее описан пример пользовательского класса валидатора.
using System;
using System.Web;
using System.Web.Util;
// Создаём пользовательский класс RequestCustomValidation
public class CustomRequestValidation : RequestValidator
{
public CustomRequestValidation() { }
protected override bool IsValidRequestString(
HttpContext context, string value,
RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
{
validationFailureIndex = -1; //значение по умолчанию
//This application does not use RawUrl directly so you can ignore the check.
if (requestValidationSource == RequestValidationSource.RawUrl) return true;
//Строка запроса может содержать XML
if ((requestValidationSource == RequestValidationSource.QueryString) && (collectionKey == "data"))
{
//Строка "<example>1234</example>" разрешается
if (value == "<example>1234</example>") { validationFailureIndex = -1; return true; }
else
//Далее контроль производить базовым ASP.NET анализатором
return base.IsValidRequestString(context, value, requestValidationSource, collectionKey,
out validationFailureIndex);
}
//Все др. HTTP входные данные контролировать базовым ASP.NET анализатором
else
{
return base.IsValidRequestString(context, value, requestValidationSource, collectionKey,
out validationFailureIndex);
}
}
}
Понятие стража
Концептуальный шаблон стража (gatekeeper) применяет модель конвейера к организации
инфраструктуры безопасности. Эта модель помогает укрепить безопасность.
Модель стражей предполагает, что безопасное приложение всегда имеет больше механизмов
защиты, чем это необходимо. Защищенный ресурс будет доступен или выполнен только в том
случае, если все стражи откроют к нему доступ. Если хотя бы один из них откажет в доступе,
обработка запроса будет прекращена и клиенту отправляется исключение безопасности.
Модель стражей отвечает центральному принципу создания безопасных приложений:
обеспечивать насколько возможно высокую степень защиты и создавать максимум
проблем нарушителям.
•
•
•
Первый страж в конвейере безопасности Web-приложения — IIS. Еще до того, как ASP.NET
начинает обработку запросов, IIS предоставляет важные механизмы безопасности:
Аутентификация, Авторизация, Конфиденциальность.
Второй страж – это исполняющая среда ASP.NET. (настройка конфигурации в web.config,
Web-элементы управления, Web-формы авторизации, валидаторы… )
Третьи и т. д. стражи – это пользовательские средства повышения безопасности Webприложения.
В IIS 7, при работе в интегрированном с ASP.NET режиме, первые два стража объединены.
ASP.NET может участвовать в обработке запросов с самого первого момента, а не только
после обработки ISAPI. Здесь Web-сервер интегрирует свои собственные потоки обработки
HTTP с потоками модулей HTTP ASP.NET.
Информационная уязвимость
Основными факторами, способствующими повышению информационной
уязвимости, являются следующие:
− увеличение объемов информации, накапливаемой, хранимой и обрабатываемой с помощью
компьютеров и других средств автоматизации;
− сосредоточение в единых базах данных информации различного назначения и различной
принадлежности;
− расширение круга пользователей, имеющих непосредственный доступ к ресурсам
вычислительной системы и находящимся в ней массивам данных;
− усложнение режимов работы технических средств вычислительных систем;
− автоматизация межмашинного обмена информацией, в том числе на больших расстояниях;
− слабая подготовка (недостаточная квалификация) персонала.
Классификация угроз безопасности
информации
При пассивном вторжении (перехвате информации) нарушитель только наблюдает за прохождением
информации. При активном вторжении – стремится изменить информацию, передаваемую в
сообщении. Случайные угрозы – это сбои аппаратуры, ошибки в ПО, ошибки в работе
обслуживающего персонала… Преднамеренные угрозы связаны с целенаправленными
действиями нарушителя.
Классификация систем обнаружения
атак
Системы анализа защищенности проводят всесторонние исследования систем с целью обнаружения
уязвимостей политики безопасности.
Для обнаружения атак можно использовать модели адаптивной защиты – обнаружение и
противодействие несанкционированному доступу в реальном времени. Работа обманных систем
заключается в том, что они эмулируют те или иные известные уязвимости, которых в реальности
не существует.
Обнаружение совершённых атак реализуется посредством анализа журналов регистрации ОС,
прикладного ПО, сетевого трафика.
Ссылки
1.
Метью МакДональд, Марио Шпушта.
ASP.NET 2.0 на C# 2005 для профессионалов, 2005
http://jskreator.narod.ru/proaspnet20cs/glance.htm
2.
Гладких А.А.
Базовые принципы информационной безопасности вычислительных
сетей : учебное пособие для студентов, обучающихся по
специальностям 08050565, 21040665, 22050165, 23040165 /
А.А.Гладких, В.Е. Дементьев;- Ульяновск : УлГТУ, 2009.- 168 с.
http://sernam.ru/book_ss.php
3.
Доминик Байер.
Microsoft ASP.NET. Обеспечение безопасности. Мастер-класс / М.: «Русская редакция»;
СПб : Питер, 2008.- 446 с.