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

    Сканеры информационной безопасности (сканеры уязвимостей) — это средства мониторинга и контроля, с помощью которых можно проверять компьютерные сети, отдельные компьютеры и установленные на них приложения на наличие проблем защищенности. Большинство сканеров позволяют детектировать уязвимости, описанные классификатором 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.
    Метки:
    • +18
    • 17,6k
    • 5
    Positive Technologies 452,85
    Компания
    Поделиться публикацией
    Комментарии 5
    • +4
      Честно говоря, было бы еще интересно почитать про сами тесты и обзоры сканеров.
      • +1
        Это да, но информация по тестам конфиденциальна и строго для служебного пользования, так что показать их довольно-таки проблематично, хотя мы подумаем, что можно сделать.
      • 0
        ptsecurity
        Было бы интересно узнать как вы тестируете GUI, можете раскрыть эту тему?
        • 0
          В скором времени мы подготовим некоторые материалы по тестированию Web GUI.
          • 0
            Про WEB уже достаточно много написано, а вот про десктопное GUI очень мало! Вернее есть кой-какие заметки на базе TestComplete но этого мало (((

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое