lektsii_po_BP_1_modul_2


Тема 1.1 Реализация защиты во время проектирования.
Существует 3 причины уязвимости в приложениях:
А) отсутствие учета наличия уязвимостей в приложениях
Б) Разработчики не обучены написанию защищенного кода
В) человеческий фактор (ошибки разработчиков)
Основные атаки на приложения:
1)переполнение буфера происходит, когда приложения пытается сохранить в буфере слишком много данных и память за пределами буфера переписывается. Один из наиболее распространенных типов - переполнение стека.
2)ошибки анализа предполагают под собой недостаточный анализ данных введенные пользователями.
Типы ошибок:
1)ошибки канонизации – это уязвимость, возникающая, когда приложения анализируют имя файла прежде чем ОС канонизирует его. ОС канонизирует имена файлов при их обработке для определения абсолютного физического пути к файлу, получ. На вход виртуальный или относительный путь.
2)XSS – межсайтовое кодирование, применяется в интернет - приложениях. На интернет -приложениях если есть возможность вводить данные, то злоумышленник может.
3)SQL-вставки, приложения работающие с БД (нельзя вводить не переработанный язык SQL)
a) атаки типа «отказ в обслуживании» данному типу атак DoS подвержены приложения, когда сервер для обработки запроса использует больше ресурсов, чем требуется клиенту для отправки запроса.
b) Криптографический взлом- включает в себя проведение крипто-анализа с целью получения переданных вами данных.
Атаки с использованием посредника : (нужно вводить аутентификацию)
Атака: взлом паролей (перебор паролей)
Тема 1.2 Проектирование защиты приложений
Самое лучшее – всесторонняя защита
Реализация: компания Microsoft стратегия SD^3
Включает 3 основных принципа:
1)защита при проектировании(разработчики должны следовать принципам создания защищенного кода и реализовывать функции защиты, чтобы устранить возможные уязвимости)
2)защита по умолчанию: если приложение защищено по умолчанию конечные пользователи могут устанавливать его не изменяя параметры по умолчанию. Неиспользуемые или снижающие уровень защиты компоненты отключены и чтобы их включить необходимо это сделать явно.
3)защита при развертывании. После установки приложения можно поддерживать его защиту добавляя исправления системы безопасности, проводя мониторинг атак и выполняя аудит для выявления фактов злонамеренного использования.
Принцип 1: требует использования наименьших привилегий разделения привилегий и уменьшения поверхности атаки приложения.
Рекомендации по реализации принципа 1: а)если приложение хранит или передает данные необходимо использовать шифрование. Б) использовать механизмы аутентификации, встроенные в .Net Framework. В)используйте механизмы .Net Framework для выполнения авторизации г)для реализации сетевого взаимодействия исп.стандартные сетевые протоколы. г)применяйте принцип наименьших привилегий (проектировать и реализовывать приложения следует так, чтобы они использовали минимальные привилегии необходимые для выполнения нужных действий. Д)при проектировании ориентироваться на защиту т.е нужно учесть требования отдела безопасности. Е) применяйте принцип разделения привилегий (проектировать приложения так, чтобы повседневные функции и функции управления выполнялись в отдельных процессах и отдельных контекстах безопасности) ж)следуйте рекомендациям по уменьшению поверхности атаки: приложение должно иметь минимальную поверхность атаки, предлагая пользователю простейший из возможных интерфейсов и предоставляя минимум способов ввода запросов. Ж1) принимайте входящие подключения через минимальное количество портов. Ж2)минимизируйте число запущенных служб. Ж3) минимизируйте число страниц в Web-приложениях. Ж4) минимизируйте число учетных записей, имеющих право использовать приложения. Ж5) минимизируйте число доступных пользователю методов аутентификации. Ж6) минимизируйте число методов ввода данных. Ж7) минимизируйте число компонентов установленных по умолчанию.
Принцип 2: В большинстве случаев после установки приложение имеет параметры по умолчанию. Не следует рассчитывать на то, что пользователи будет следовать инструкциям и изменять параметры по умолчанию. Не следует рассчитывать на то, что пользователи будут следовать инструкциям и изменять параметры по умолчанию или удалять ненужные компоненты, чтобы повысить уровень защиты, поэтому следует сделать приложения максимально защищенными по умолчанию, предоставляя при этом возможность добавлять нужные пользователю функции после установки.
Рекомендации по реализации принципа 2:
1)Убедитесь, что программа установки по умолчанию установит только необходимые компоненты приложения.
2)Во время настройки предоставляйте наиболее ограничивающее разрешение.
3)изменяйте параметры приложений.
Рекомендации по реализации принципа защиты при развертывании:
Процесс развертывания не завершается выпуском приложения необходимо поддерживать защиту приложения установленного на клиентском ПК.
1)Необходимо иметь процедуру отслеживания информации об обнаруженных уязвимостях и выпуска обновлений закрывающих эти уязвимости.
2)необходимо предоставить клиентам систему, позволяющую наблюдать за событиями, происходящими во время работы приложения.
3)приложение должно безопасно управлять сбоями и ошибками, раскрывая конечным пользователям минимум информации, но позволяя администратору определить причину проблемы и устранить ее.
Доступ к ресурсам и использование наименьших привилегий. Приложение спроектировано с учетом данного принципа не требует для работы прав администратора, чтобы использовать принцип наименьших привилегий необходимо:
1)не запрашивать большего уровня доступа, чем необходимо.2)создавать файлы и разделы реестра там где стандартные пользователи могут их изменять.
Тема 2: Рекомендации по созданию защищенного кода.
2.1 Проверка входных данных.
Все входные данные следует рассматривать как угрозу. Любые данные, полученные непосредственно от пользователя или другого приложения, должны пройти через трехплановую процедуру проверки прежде чем их можно считать безопасными.
Шаг 1 процедуры: ограничение, отклоняющее входные данные, если они не соответствуют ожидаемому типу, длине, формату и диапазону.
Шаг 2 Реализация защиты во: отклонение. Отклоняйте входные данные, которые удовлетворяют требованиям отклонения и содержит известные вредоносные значения и фразы.
Шаг 3:очистка. Очищайте входные данные от символов, которые могут иметь особое значение для приложения.
2.1.1 Наложение ограничения на входные данные.
Существует несколько способов проверки данных, включая регулярные выражения, строгое определение типов, проверяющие элементы управления ASP.Net, выражения с типизированными данными, свойство string.Length.
Возможности по ограничению данных:
Проверяемые данные Способ проверки
А)тип 1)строгое определение типа
2)регулярные выражения
3)элементы управления ASP.Net
Б) длина 1)регулярное выражение
2) свойство string.Length
В)формат 1)строгое определение типов
2)регулярные выражения
Г)диапазон 1)элементы управления ASP.Net
2) сравнение типизированных данных
Использование регулярных выражений для ограничения входных данных строкового.
Регулярное выражение – это набор символов, который можно сравнить со строкой, чтобы определить удовлетворяет ли формат этой строки определенным требованиям.
Классы, выполняющие анализ регулярных выражений содержатся в сборке System.Text.RegularExpressions.
Пример: консольное приложение, принимающее в качестве входных данных и определяет соответствует ли 1-ая строка (хранится регулярное выражение) второй строке.
Regex.YsMatch (args[1], args [0])
Метод, выполняющий проверку соответствия регулярного выражения строке.
Регулярное выражение : \d{5}$ (abc 11111)
Основные символы регулярных выражений
Символы:
\-слэш помечает следующий за ним символ, как специальный символ, букву, обратную ссылку или восьмиричную управляющую последовательность.
()-отмечает начало и конец подвыражения
^-соответствие должно начинаться в начале строки
$-соответствие должно обнаруживаться в конце строки
*-соответствует предыдущему элементу 0 или более раз.
+-соответствует предыдущему элементу 1 или более раз
?-соответствует предыдущему элементу 0 или 1 раз.
[ ]-заключает в себя множество символов, соотв. Любому из указанных символов.
[а-е ]-диапазон символов
{ n}-описание: предыдущий элемент повторяется ровно n-раз.
{ n,}-предыдущий элемент повторяется минимум n-раз.
{ n,m}- предыдущий элемент повторяется минимум n-раз, но не более m-раз.
|- соответствует любому элементу, разделенному вертикальной чертой.
\w- соответствует любому алфавитно-цифровому знаку
\W- соответствует любому символу, не являющемуся буквой.
\s- соответствует любому знаку пробела
\S- соответствует любому знаку, не являющемуся пробелом
\d- соответствует любой десятичной цифре.
Использование строк в определении типов и сравнение типизированных данных для нестроковых данных.
Int a=int.Parse (TextBox.Text);
If (!((a>=50)&&(a<=100)))
Thraw new exception (‘’……..’’)
2.1Проверка данных элементов управления ASP.Net
Web-приложения атакуются чаще всего, и это происходит по следующим причинам:
-общедоступность web-приложений
-злоумышленник легко может проанализировать форму HTML, чтобы выяснить какой тип имеют данные принимаемые приложением
-существует много доступных средств автоматизации процесса взлома.
В ASP имеются доп.средства используемые для проверки данных (5 элементов управления в пространстве имен System.Web.UI.WebControls).
1)элемент управления ReguiredfieldValidator-проверяет поле, содержащее минимум 1 символ.
2)элемент управления CompareValidator- проверяет соответствует ли в точности данные в одном поле данным в другом поле.
3)RangeValidator- проверяет входят ли введенные данные в определенный диапазон символов верхнего и нижнего регистров. Можно проверять число, даты, символы.
4)RegularExpressionValidator- проверяет введенные данные на соответствие определенному регулярному выражению.
5)CustomValidator-позволяет создавать определенные методы, для проверки входных данных.
Чтобы использовать элементы управления необходимо выполнить следующее:
1)добавить в форму эл.управления, принимаемые данные
2)добавить один из перечисленных элементов.
3) опред.свойства ErrorMessage эл.управления исп.для эл.управления.
4)Опред. Св-во ControlToValidate задав ему значение имеем элемент управления шага 1.
5)укажите дополнительные параметры специфичные для каждого типа элемента управления используя метод проверки.
6)Добавьте код проверяющий состояния элементов управления. Однако, ASP.Net не будет останавливать обработку входных данных, если они не удовлетворяют требованиям. Необходимо вручную проверять свойство isValied если свойство имеет значение folse,не следует доверять входным данным.
Отклонение подозрительных данных.
Иногда после ограничения данных, требуется искать вредоносное содержимое определенного типа. Например, можно искать слово script в HTML данных подобное отклонение данных затрудняет, хотя и не делает невозможным проведение подобных атак. Например, злоумышленник может обнаружить, что алгоритм фильтрации чувствителен к регистру символов и использует это для атаки. Для осуществления могут принимать регуляр.сам по себе является ненадежным способом.
Исключение.
Иногда разрешенные символы могут использоваться для проведения атаки. Например, злоумышленник может использовать апостроф в атаках со вставкой в SQL. Так как эти символы являются разделительными знаками в командах SQL. В таких случаях нужно исключать символы, которые могут использоваться для атак, заменяя их безопасными специальными символами. Например, в SQL 2 апострофа подряд интерпретируются как один, не является разделителем. Для подобных замен в классах string есть метод <имя строки>.Replace(‘’,’’’,’,’’,’’,’’)
Решение проблем канонизации.
Решение проблем канонизации в приложениях Windows Form.
Если имя файла проверяется до того как ОС канонизирует его, злоумышленник может передать имя, которое приложение не сможет определить как недопустимое. Защищаться от атак с использованием ошибок канонизации можно вручную канониз.путь перед его проверкой. Кроме того нужно следить за тем чтобы путь состоял только из разрешенных символов, а не просто определял действителен ли путь.
Выполнить канонизацию можно 2 способами:
1)регулярные выражения
2)канонизируемый файл, использующий специальный метод System.Patch.GetFullPatch существует еще несколько методов в этом классе для предотвращения ошибок канонизации. Combine-комбинирирует 2 строки представл.пути позволяя самостоятельно создавать путь к файлу, уменьшая вероятность возникновения ошибок канонизации. GetDirectoryName- возвращает абсолютный путь к папке, в которой находится файл без имени и расширения файла
GetExtension-возвращет расширение файла
GetFileName-возвращает имя файла и расширения без шифр.о папке
isPatchRooted-позв.определить является ли путь абсолютным или относительным.
Если TrueTo, то абсолютный, если folse то относительный.
2.3 Предотвращение атак со вставками SQL
Можно значительно уменьшить вероятность совершения ошибок разработчиками, которые могут привести к возникновению атак с использованием вставок SQL и упростить процесс их выявления и исправления если создаются отдельные классы для взаимодействия с БД. Чтобы с кодом было проще работать и исправить не следует уст.подключить к БД непосредственно из методов, выполн. Функции не относящиеся к работе с БД,
Настройки разрешения SQL.
Начиная разработку приложений работающих с БД нужно кроме планирования структуры БД также спланировать и назначить привилегии на доступ к БД. Каждая группа пользователей приложения должна иметь отдельную роль в БД каждой из этих ролей следует предоставлять минимум требуемых привилегий. Всегда, когда возможно, для обращения к БД используйте хранимые процедуры вместо динамически генерируемого когда SQL. Если возможно для доступа к данным, следует использовать параметриз. Хранимые процедуры.
С точки зрения безопасности это предоставление следующих преимуществ:
Возможность ограниченных привилегий пользователя, чтобы пользователи могли только запускать хран.процед.нет необходимости предоставлять им доступ к таблице.
Возможность дополнительной проверки данных в самой хранимой процедуре
Применение параметров уменьшает риск атаки со вставкой SQL
Параметры SQL это элементы команд, которые при обращении к БД заменяются на значения, указанные отдельно, поэтому нет возможности включить в них какие либо команды SQL.
2.4Предотвращение атак с использованием межсайтового кодирования.(XSS)
Эти атаки используют конечных пользователей, злоумышленник помещает код HTML или клиентский сценарий во входные данные, которые сервер затем показывает другим пользователям. Данные атаки могут привести к тому, что сервер будет управлять пользователем опасное или нежелательное содержимое.
Атаки эти направлены на приложения 2 типов:
-форумы, гостевые книги и страницы с комментариями, на которых данные введенные пользователем могут рассматривать другие пользователи.
-динамически генерируемые страницы, отображающие параметры запроса.
Для предотвращения атак с использованием межсайтового кодирования нужно тщательно проверять данные, введенные пользователями. В частности нужно отслеживать код HTML и клиентские сценарии, заключенные в угловые скобки “< >”. Если не планируется разрешить пользователям создавать документы HTML можно очищать входные данные следующим образом
String goodInput=Http Utility.HtmlEncode(badInput)
Если пользователям разрешено вводить код HTML, то лучше разрешить использование ограниченного набора тэгов. Очищая входные данные при помощи метода, а затем преобразуя некоторые тэги обратно в код.
2.5Сообщение об ошибке при обработке сбоев
Если при создании приложения следовать рекомендациям, то при попытках атак приложение будет генерировать сообщение об ошибках, чтобы обеспечить защиту после возникновения исключения или другого сбоя нужно ограничить привилегии пользователя, записать сведения об ошибке и сообщить пользователю минимум информации. ASP.Net представляет хороший пример того, как надо сообщать об ошибках: предоставляется подробное сообщение об ошибке, включающее конфиденциальный исходный код, полный физический путь к файлу и информацию из стека. ASP.Net уменьшает риск предоставления подобных сведений, показывая их только пользователям локального компьютера.Если приложение работает без прав администратора, то, чтобы иметь возможность записывать подробные сведения об ошибках нужно зарегистрировать исключение событий на сервере приложений.
Вручную:
-войдите на сервер приложений под учетной записью администратора
-в реестре открыть раздел HKLM|System|CurrentControlSet|ServicesEventhog|Application
-создать раздел имя которого является именем источника событий MyApplication. После этого создайте метод для выполнения записи сообщения в журнал. Чтобы получить доступ к классам Eventhog нужно использовать пространство имен System.Diagnostics
Eventhog myhog = new Eventhog (“Application”);
myhog Source = “ MyApplication”;
myhog.WhiteEntry(“сообщение”,type,event IO,catecory)
Управление сообщениями об ошибках на основе свойств пользователя.
Рекомендуется хранить информацию в журнале событий на сервере, так как доступ на чтение журнала имеет только системный администратор. Чтобы при обработке Web-запросов определить работает ли пользователь на локальном компьютере можно сравнить Ip-адрес пользователя с адресом 127.0.0.1, который является специальным адресом, используемым локальным компьютером.
Reguest.UserHostAddress сравнить с адресом
Закрытие открытых подключений.
Чтобы снизить вероятность успешного проведения атак типа «отказ в обслуживании» следует закрывать все открытые подключения, когда происходит необрабатываемое исключение , в противном случае злоумышленник сможет непрерывно генерировать ошибки и занять весь пул доступных подключений.
Try {
conn.Open( );
}
catch{
}
finally{
conn.Close ();
}
Переход в более безопасный режим. Хотя большинство исключений и сбоев происходит из-за ошибки пользователей всегда следует предполагать, что ошибка была намеренно вызвана злоумышленником, а, значит, код надо писать таким образом, чтобы при возникновении ошибки назначался более безопасный набор разрешений чем был назначен до этого.
Тема3:Проверка приложений на наличие уязвимостей.
3.1Автоматизированное тестирование модулей.
3.1.1.Тестирование модулей.
Тестирование модулей- это прием, используемый разработчиками для автоматического тестирования компонентов приложения, после внесения изменений. Тесты модулей- это модули, проверяющие другие модули.
Тесты модуля называются модуль, который должен возвратить предсказуемый результат после чего анализируется результат. Если на выходе получены недопустимые данные- тест не пройден с помощью этого можно например проверить гарантирует ли этот метод исключения, когда получает некорректный запрос.
3.1.2Упреждающее тестирование
Это методология, следуя которой разработчики создают тесты модулей раньше чем сами модули.
Достоинства:
-если создавать тесты модулей для каждой значимой функции приложения невозможно забыть реализовать какую-либо функцию, т.к. код не сможет пройти тесты модулей, пока работа не будет завершена
-тесты модулей указывают на функции защиты и контрмеры, которые еще не реализованы
Тесты модулей могут использоваться на протяжении всего жизненного цикла приложения и выявить ошибки, внесенные обновлениями и новые функции.
Концепция упреждающего тестирования:
-создайте методы для проверки безопасности каждой значимой функции включая следующие методы, вступающие в действие, которые передаются допустимые данные.
-методы, сообщающие об ошибках.
-методы, выполнение которых невозможно, если пользователь не имеет достаточно привилегий.
-создайте или расширьте методы приложения.
-проведите тестирования.
Если при тестировании модулей безопасность не является приоритетом проверяется обычно успешное выполнение условия. Если значение х передается методу у, должно возвращаться значение Z.
Тестирование такого типа важно для выявления проблем функционирования приложения. Чтобы выявить уязвимости нужно проверить как методы реагируют на потенциально вредоносные входные данные. Тест считается пройденным, если код сгенерировал исключения.
3.2Проверка сборок на наличие уязвимостей.
3.2.1Тестирование системы безопасности перед выпуском приложения
Перед выпуском приложения нужно оценить потенциальные уязвимости выполнив следующее:
1)оценить поверхность атаки определив все точки прямого ввода данных, включая страницу ASP.Net Web-службы и открытые методы.
2)Определите наиболее вероятные цели для атаки, а также потенциальных злоумышленников. Нужно исходить из предположения, что приложение уязвимо к атакам всех основных типов если нет специальной защиты.
3)Оцените защиту коммуникаций, т.е может ли злоумышленник перехватить трафик и извлечь конфиденциальную информацию.
4)Убедитесь, что приложение по умолчанию использовать наиболее безопасные конфигурации.
5)Убедитесь, что выполняется принцип наименьших привилегий.
6) Проверьте устойчивы ли серверные компоненты к атакам DOS.


Приложенные файлы

  • docx 23756817
    Размер файла: 32 kB Загрузок: 0

Добавить комментарий