Pull to refresh

Тестирование сканеров безопасности веб-приложений: подходы и критерии

Reading time 8 min
Views 23K
Сканеры информационной безопасности (сканеры уязвимостей) — это средства мониторинга и контроля, с помощью которых можно проверять компьютерные сети, отдельные компьютеры и установленные на них приложения на наличие проблем защищенности. Большинство сканеров позволяют детектировать уязвимости, описанные классификатором WASC Threat Classifcation. В сегодняшнем хабратопике мы рассмотрим некоторые вопросы, связанные с тестированием сканеров информационной безопасности веб-приложений как программных продуктов.

Современный сканер веб-приложений — это многофункциональный и весьма сложный продукт. Поэтому его тестирование и сравнение с аналогичными решениями имеет целый ряд особенностей.

Тестовая процедура


В статье «Building a Test Suite for Web Application Scanners» изложены общие принципы тестирования сканеров, на которые мы будем опираться далее. Одним из таких принципов является Тестовая процедура для сравнения работы различных сканеров веб-приложений. В немного модифицированном виде эта процедура выглядит следующим образом:

  1. Подготовить необходимый тестовый контент для функциональной проверки всех технических требований и развернуть тестовые стенды.
  2. Инициализировать тесты, получить все необходимые настройки для тестов.
  3. Сконфигурировать сканируемое веб-приложение и выбрать для него тип уязвимости и уровень защиты.
  4. Запустить сканер с выбранными настройками на тестируемом веб-приложении и пройти набор функциональных тестов.
  5. Подсчитать и классифицировать найденные сканером веб-объекты (уникальные ссылки, уязвимости, векторы атаки и т. п.).
  6. Повторить шаги 2—5 для каждого типа уязвимостей и уровней защиты.

Изменения после каждой итерации необходимо заносить в сводную таблицу результатов детектирования объектов. Выглядеть это должно приблизительно так:



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

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

  1. В качестве одной уязвимости рассматривать класс эквивалентных уязвимостей, которые могут быть найдены в тестовом веб-приложении. Например, для SQL-инъекций классом эквивалентных уязвимостей можно считать все уязвимости, найденные для одного и того же параметра GET-запроса к приложению. Другим словами, если имеется некий уязвимый параметр id, изменение которого вызывает сбой веб-сервера или базы данных, то все векторы атаки, использующие этот параметр, можно считать эквивалентными с точностью до перестановки параметров: example.com/page.php?id=blabla ~ example.com/page.php?a=1&id=bla&b=2.
  2. Разработать простейшие тестовые приложения, реализующие или моделирующие некоторую уязвимость, но используя различные фреймворки и разворачивая их на множестве вариантов операционных систем, различных веб-серверах, с использованием различных баз данных, с доступом по различным видам сетевых протоколов, а также через различные цепочки прокси.
  3. Развернуть на тестовых стендах множество различных CMS, уязвимых приложений (DVWA, Gruyere, OWASP Site Generator и т. п.) и сканировать их различными сканерами безопасности. Общее число уязвимостей, найденных всеми сканерами, взять за эталон и использовать в дальнейших тестах.

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

Типы уязвимостей для реализации в тестовом контенте для проверки сканера можно взять из классификатора WASC Threat Classification.

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

По результатам сканирования получаем числовые векторы вида

(уровень защиты, кол-во обнаруженных объектов, False Positive, False Negative, всего объектов, время сканирования)

Затем необходимо ввести метрику качества сканирования, которою можно будет использовать для сравнения показателей и сканеров между собой. В качестве подобной метрики достаточно использовать простейшую евклидову метрику.

Виды тестовых испытаний


Еще одна статья, на которую можно опираться при тестировании сканеров веб-приложений, называется «Analyzing the Accuracy and Time Costs of Web Application Security Scanners». В этом материале описывается проведение испытаний различных сканеров (BurpSuitePro, Qualys, WebInspect, NTOSpider, Appscan, Hailstorm, Acunetix) и для каждого конкретного инструмента предлагается проводить четыре типа испытаний:

  1. Выполнить сканирование веб-приложения в режиме Point and Shoot (PaS) и определить число найденных и подтвержденных уязвимостей.
  2. Выполнить повторное сканирование после предварительного «обучения» и настройки сканера на работу с данным типом приложений, определить число найденных и подтвержденных уязвимостей в этом случае.
  3. Оценить точность и полноту описания найденных уязвимостей.
  4. Оценить общее время, потраченное специалистами на подготовку и проведение тестирования, анализ и обеспечение качества результатов сканирования.

Режим PaS — это запуск сканирования со стандартными параметрами сканера. Проходит по схеме «установка цели — сканирование — получение результата».

Обучение — включает в себя любые конфигурации настроек, изменение скриптов, связь с поставщиками сканера и т. п.

Для определения количества времени, которое специалистам необходимо затратить для получения качественного результата, в статье предлагается пользоваться простой формулой:

Общее время = Время обучения + #False Positive * 15 мин. + #False Negative * 15 мин.

В ходе каждого испытания нужно применять тестовую процедуру, которую мы описывали выше.

Критерии оценки для сканеров веб-приложений


В еще одной полезной статье «Top 10: The Web Application Vulnerability Scanners Benchmark» авторы предлагают общий поход к сравнению характеристик сканеров, а также набор таких характеристик с примерами. Оценку возможностей сканеров веб-приложений в этой статье предлагается задавать в табличном виде, используя следующие критерии:

  1. Сравнение цены продукта по отношению к оценкам критериев. (A Price Comparison — in Relation to the Rest of the Benchmark Results). Пример сравнения можно посмотреть в сводной таблице.
  2. Универсальность применения сканера — это число поддерживаемых протоколов и векторов доставки — методов доставки данных к серверу (Scanner Versatility — A Measure for the Scanner's Support of Protocols & Input Delivery Vectors). Векторы доставки включают в себя такие методы доставки данных к серверу, как HTTP-параметры строк запроса, параметры HTTP-body, JSON, XML, двоичные методы для конкретных технологий — таких как AMF, Java-сериализованные объекты и WCF. Пример сравнения можно посмотреть в сводной таблице.
  3. Количество поддерживаемых векторов атаки: количество и тип активных плагинов сканера (Attack Vector Support — The Amount & Type of Active Scan Plugins (Vulnerability Detection)). Пример сравнения можно посмотреть в сводной таблице.
  4. Точность обнаружения CSS (Reflected Cross Site Scripting Detection Accuracy). Пример сравнения можно посмотреть в сводной таблице.
  5. Точность обнаружения SQL-инъекций (SQL Injection Detection Accuracy). Пример сравнения можно посмотреть в сводной таблице.
  6. Точность обхода структуры веб-приложения и обнаружения локальных файлов. (Path Traversal / Local File Inclusion Detection Accuracy). Пример сравнения можно посмотреть в сводной таблице.
  7. Удаленное использование файлов, XSS, фишинг через RFI. (Remote File Inclusion Detection Accuracy (XSS / Phishing via RFI)). Пример сравнения можно посмотреть в сводной таблице. Пример тест-кейсов RFI приведен на схеме.
  8. WIVET-сравнение: автоматизированный краулинг и получение входных векторов для атаки (WIVET (Web Input Vector Extractor Teaser) Score Comparison — Automated Crawling / Input Vector Extraction). Пример сравнения можно посмотреть в сводной таблице.
  9. Адаптивность сканера: количество дополнительных возможностей сканера для преодоления защитных барьеров (Scanner Adaptability — Complementary Coverage Features and Scan Barrier Support). Пример сравнения можно посмотреть в сводной таблице.
  10. Сравнение особенностей аутентификации: количество и тип поддерживаемых способов авторизации и аутентификации (Authentication Features Comparison). Пример сравнения можно посмотреть в сводной таблице.
  11. Количество дополнительных возможностей сканирования и встроенных механизмов. (Complementary Scan Features and Embedded Products). Пример сравнения можно посмотреть в сводной таблице.
  12. Общее впечатление о работе основной функции сканирования (General Scanning Features and Overall Impression). Пример сравнения можно посмотреть в сводной таблице.
  13. Сравнение лицензий и технологий (License Comparison and General Information). Пример сравнения можно посмотреть в сводной таблице.

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

Типы тестов для сканеров веб-приложений


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

  • Базовые функциональные (smoke) тесты должны проверять работоспособность основных низкоуровневых узлов сканера: работу транспортной подсистемы, подсистемы конфигурации, подсистемы логирования и т. п. При сканировании простейших тестовых целей не должно быть сообщений об ошибках, exceptions и traceback в логах, сканер не должен зависать при использовании различных транспортов, редиректов, прокси-серверов и т. п.
  • Функциональные (functional) тесты должны реализовать проверку основных сценариев для проверки технических требований. Необходимо проверять работоспособность каждого сканирующего модуля по порядку при различных настройках модуля и тестового окружения. Выполняются позитивные и негативные тестовые сценарии, различные стресс-тесты с использованием больших массивов корректных и некорректных данных, оправляемых сканеру в ответ от веб-приложения.
  • Тесты на сравнение (compare) функциональности, в ходе которых выполняется сравнение качества и средней скорости поиска объектов выбранным модулем сканера с аналогичными по функционалу модулями в продуктах-конкурентах. Для каждого конкретного сканирующего модуля должны даваться определения, что подразумевать под объектами для него и качеством их поиска.
  • Тесты на сравнение показателей оценочных критериев (criteria), в ходе которых проверяется, что скорость и качество поиска объектов каждым сканирующим модулем в каждой новой версии тестируемого сканера — не ухудшились по сравнению с предыдущей версией. Определения скорости и качества должны задаваться так же, как для тестов на сравнение функциональности: за тем исключением, что в данном типе тестов в качестве конкурента для тестируемого сканера выступает его предыдущая версия.

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

Спасибо за внимание, будем рады ответить на вопросы в комментариях.

Автор: Тимур Гильмуллин, группа автоматизированного тестирования Positive Technologies.
Tags:
Hubs:
+18
Comments 5
Comments Comments 5

Articles

Information

Website
www.ptsecurity.com
Registered
Founded
2002
Employees
1,001–5,000 employees
Location
Россия