Как выбрать сканер уязвимостей веб-приложений?

Нередко мне задают вопрос: «какой сканер веб-приложений – самый лучший?» Как водится, на общий вопрос можно дать общий ответ типа «смотря для каких целей». В данной заметке я решил рассмотреть задачу сравнения сканеров веб-приложений.

Сразу скажу, что эта заметка скорее обучающая, для новичков, чем отвечающая на конкретные вопросы. Для экспертов в ИБ заметка будет, наверное, капитанством.

В заметке мы ограничимся только сканерами, работающими с веб-приложениями методом черного ящика: т.е. сканер взаимодействует с веб-приложением так же, как и типичный пользователь, через веб-интерфейс по сети по протоколу HTTP(S).

В целом, если говорить о задаче сравнения сканеров веб-приложений, можно рассмотреть следующие задачи:

• сравнение функций сканеров;
• бенчмарк сканеров с целью определения эффективности их работы на самых различных видах веб-приложений (качество и скорость поиска уязвимостей);
• выбор сканера под нужды заданного владельца веб-приложений.

Сравнение функциональных возможностей

Первую задачу, в целом, понятно как решать. Методика сравнения функциональных возможностей сканеров такова: необходимо принять за основу сравнения некоторый контрольный список  [1] возможностей идеального сканера и оценить пилотируемые инструменты на поддержку этих возможностей. Итогом является таблица, в строках которой перечислены критерии сравнения, в столбцах – инструменты, а в ячейках дана оценка каждому средству по данному критерию.

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

Бенчмарк эффективности сканеров

Со второй задачей возникают трудности. Методика сравнения эффективности сканеров вообще (без привязке к классу приложений или типам уязвимостей) является предметом споров и разногласий в сообществе и по сей день.

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

У описанного подхода есть два недостатка:

• указанные показатели зависят от тестовой выборки;
• такое определение эффективности является бесполезным с практической точки зрения.

Первый недостаток означает, что показателями эффективности при сравнении инструментов между собой можно манипулировать, включая или исключая из тестовой выборки для бенчмарка те или иные веб-приложения или уязвимости в них. Данное обстоятельство порождает отдельную нетривиальную задачу: как построить и доказать корректность тестовой выборки веб-приложений, чтобы это устроило все стороны сравнительного теста?

Второй недостаток требуется раскрыть подробнее. Рассмотрим в качестве примера следующую ситуацию: пусть сравниваются два сканера – А и Б; у первого сканера показатели эффективности на заданной выборке – (0.65, 0.01), а у второго – (0.35, 0.01). На первый взгляд, сканер А лучше сканера Б. Но на самом деле, без информации о том, как соотносятся множества обнаруженных сканерами уязвимостей, сделать вывод о победителе не представляется возможным. Например, сканер А мог обнаружить в тестовой выборке все уязвимости к атакам класса XSS и ни одной уязвимости к атакам других классов, а второй – все уязвимости к атакам класса SQL injection и ни одной уязвимости к атакам других классов; при этом 65 и 35 – это количественные характеристики тестовой выборки по классам уязвимостей к атакам XSS и SQL injection соответственно.

Отдельным важным фактором при сравнении эффективности сканеров является оценка эффективности их crawler’ов. Так как у автоматических средств сканирования первым этапом анализа является навигация по веб-приложению и определение точек ввода входных данных (DEP’ов, от “Data Entry Points”), плохие результаты на этом этапе существенно влияют на возможность найти уязвимости при тестировании найденных DEP’ов. Так, например, известны типичные проблемы сканеров при обходе современных веб-приложений класса SPA (Single Page Applications) и приложений, навигация по которым реализована исключительно через JavaScript. Подробнее про эти проблемы можно узнать из доклада на первой встрече OWASP Russia или из нашей статьи .

Выбор сканера для себя

Понимая особенности решения задач в первой и второй формулировках, стоит обратиться к третьей задаче: «как выбрать сканер под нужды владельца конкретных веб-приложений». И тут-то возникает вот это вот: «смотря для каких целей». Так как мы не рассматриваем задачу выбора сканера консалтинговыми компаниями в области ИБ, сосредоточимся на задачах владельцев веб-приложений.

Напомним, что с помощью сканеров веб-приложений можно обнаружить уязвимости следующих категорий:

1. Уязвимости этапа кодирования. Лучше всего среди уязвимостей этого типа обнаруживаются т.н. уязвимости, связанные с некорректной обработкой входных и выходных данных (англ. Injection Flaws, в т.ч. возможность SQL injection, возможность XSS и т.д.), а хуже всего – логические уязвимости.
2. Уязвимости этапа внедрения и конфигурирования приложения. К этим уязвимостям относятся некорректные настройки окружения веб-приложения: веб-сервера, сервера приложений, SSL/TLS, фреймворка, сторонних компонент, наличие DEBUG-режима и т.п.
3. Уязвимости этапа эксплуатации приложения. К этим уязвимостям относятся использование устаревшего ПО (не обновлённого веб-сервера, фреймворка, сторонних библиотек и т.п.), простых паролей, хранение архивных копий на веб-сервере в общем доступе, наличие в общем доступе служебных модулей (phpinfo) и т.п.

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

---

В ручном режиме оператор работает с анализируемым приложением через веб-браузер, который подключен к приложению через сканер как через промежуточный прокси-сервер. При этом оператор наблюдает все HTTP-запросы и HTTP-ответы в сканере и по своему выбору может на их основе составить и отправить необходимые тестовые запросы. При работе со сканером в таком режиме имеются следующие особенности: во-первых, предъявляются повышенные требования к квалификации оператора, во-вторых, оператору важно получить от сканера максимум удобных инструментов для автоматизации создания и отправки тестовых запросов и анализа ответов приложения на них. Типичными представителями указанного класса сканеров являются Burp Suite и ZAP Proxy.

В автоматическом режиме работы от оператора требуется только сконфигурировать параметры запуска сканера: указать URL приложения и логин/пароль пользователя (при тестировании закрытой части). Типичными представителями указанного класса являются инструменты HP WebInspect, Acunetix и т.п.

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

---

Рассмотрим типичные сценарии использования сканеров:

1. Запуск в процессе тестирования веб-приложения в тестовом окружении для обнаружения уязвимостей этапа кодирования. Варианты:
   1. запускается службой ИБ при приемке веб-приложения, разработанного на заказ сторонним подрядчиком;
   2. запускается службой ИБ после прохождения очередного релиза приложения, разрабатываемого внутри компании, всех тестовых процедур;
   3. запускается тестировщиками веб-приложения во время тестовых процедур;
   4. запускается службой ИБ по инициативе (тикету) разработчиков (например, после добавления новых элементов в графический интерфейс).
   
   
2. Запуск после разворачивания новой версии веб-приложения в продукционной среде для обнаружения уязвимостей этапа конфигурации. Варианты:
   1. запускается службой ИБ перед подписанием бумажки а-ля «ввод в эксплуатацию разрешаю»;
   2. запускается службой эксплуатации (администраторами/девопсами) в рамках соблюдения регламента по безопасному вводу в эксплуатацию новых релизов/приложений.
   
   
3. Периодическое сканирование веб-приложения в продукционной среде для обнаружения уязвимостей этапа эксплуатации. Обычно запускается на периодической основе службой ИБ для внутреннего контроля соблюдения политик администрирования ИТ-ресурсов.

Зачем были перечислены эти сценарии? Каждый сканер (и режим работы) предъявляет определенные требования к оператору. Квалификация важна при выборе режима работы сканера, при конфигурировании запусков сканера, при интерпретации результатов (ложное или неложное срабатывание, критичность неложного срабатывания).

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

1. Автоматизируемость запуска (например, наличие интерфейса командной строки или API) и возможность внедрения в процесс непрерывной интеграции (CI).
2. Воспроизводимость результатов сканирования: на одной и той же сборке анализируемого приложения прогон средства должен давать стабильные результаты.
3. Удобство перепроверки: сканер должен предоставлять возможность проверить, была ли исправлена известная уязвимость в новом релизе (желательно без полноценного прогона), а также классифицировать найденные уязвимости на новые или вновь открывшиеся старые.

Резюме

Резюмируя заметку, можно сделать следующие выводы:

1. Функциональное сравнение сканеров сделать методически несложно. Имея список функциональных критериев, можно сравнительно недорого получить оценку соответствия этим критериям для каждого инструмента из списка на выбор.
2. Бенчмарк сканеров – это не то, на что следует ориентироваться при выборе средств. Признанных бенчмарков нет.
3. Важными шагами при выборе сканера для себя будут:
   1. определение сценария использования сканера и оценка требуемой квалификации оператора;
   2. определение существенных функциональных требований к сканеру и сравнение инструментов по существенным критериям (примеры таких критериев – возможность запуска через CLI, возможность интеграции с такими-то ИТ-системами, поддержка многопользовательского режима работы и т.п.);
   3. оценка поддержки сканером веб-технологии вашего приложения; примеры веб-технологий, где это будет иметь значение:
      1. GWT и прочие технологии с нетривиальным способом передачи параметров серверу или менеджментом сессий;
      2. RIA и SPA-приложения, а также веб-приложения, интерфейс которых существенно динамический (т.е. его нельзя обойти, статически анализируя код веб-страниц);
      3. приложения, требующие реализации на клиенте нестандартных криптографических примитивов (см. системы класса ДБО).
   4. наличие специальных профилей сканирования под различные веб-технологии (т.е. фаззинг GWT надо проводить по одной стратегии, а приложения на ASP.NET Web Forms – по другой).

p.s. Спасибо за фидбек по заметке Денису Колегову, Алексею Синцову, Георгию Носеевичу и Сергею Герасимову.

[1] Список, например, составляется на основе комбинации критериев, перечисленных в проектах «Web Application Security Scanner Evaluation Criteria» и «OWASP Web Application Scanner Specification Project».