проф. В.К.Толстых, Технологии разработки Internet- приложений ASP.NET приложения: Безопасность Из цикла лекций «Технологии разработки Internet-приложений» для студентов 4-го курса кафедры Компьютерных технологий физического факультета Донецкого национального университета

Безопасность Плохо контролируемый физический доступ к оборудованию. Некачественное архивирование. Наличие «инсайдеров» в обслуживающем персонале. Необходима сегрегация обязанностей, шифрование данных на всех серверах, раздельное хранение ключей доступа к данным. Не храните на сайте сборки в исходных кодах, делайте предкомпиляцию в.dll -файлы. Безопасность важнейшая часть Web-приложений, и она должна приниматься во внимание с первой стадии процесса разработки. Моделирование угроз безопасности становится все более важным в современном процессе разработки программного обеспечения. Моделирование угроз это структурированный способ анализа среды ваших приложений с точки зрения возможных опасностей, их классификации и решений относительно приемов смягчения этих угроз. 1. Проблемы безопасности до подключения клиентов к сайту Помните, что система защиты ровно настолько надёжна, насколько надёжна её самая слабая часть.

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 для различных блоков программы. Среда.NET не требует существенных дополнительных вычислительных ресурсов для реализации такого контроля времени выполнения.

Пример ограничений run-time (.NET 4) Значения параметров соответствуют значениям по умолчанию.

Межсайтовые атаки 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")) { //Строка " 1234 " разрешается if (value == " 1234 ") { 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.

Основными факторами, способствующими повышению информационной уязвимости, являются следующие: увеличение объемов информации, накапливаемой, хранимой и обрабатываемой с помощью компьютеров и других средств автоматизации; cocpeдoтoчeниe в единых бaзax дaнныx инфopмaции paзличнoгo нaзнaчeния и paзличнoй пpинaдлeжнocти; pacшиpeниe кpугa пользoвaтeлeй, имeющиx нeпocpeдcтвeнный дocтуп к pecуpcaм вычиcлитeльнoй cиcтeмы и нaxoдящимcя в нeй мaccивaм дaнныx; усложнение режимов работы технических cpeдcтв вычислитeльныx cиcтeм; автоматизация межмашинного обмена информацией, в том числе на больших расстояниях; слабая подготовка (недостаточная квалификация) персонала. Информационная уязвимость

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

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

Ссылки 1.Метью МакДональд, Марио Шпушта. ASP.NET 2.0 на C# 2005 для профессионалов, Гладких А.А. Базовые принципы информационной безопасности вычислительных сетей : учебное пособие для студентов, обучающихся по специальностям , , , / А.А.Гладких, В.Е. Дементьев;- Ульяновск : УлГТУ, с.