Краткое содержание
- Несовместимость DAST / SAST.
- IAST: Buzzword и реальность.
- Третий путь.
Как мы отмечали ранее, у систем поиска уязвимостей SAST и DAST есть как преимущества, так и недостатки, поэтому проблема поиска оптимального подхода к автоматизации анализа безопасности приложений не теряет своей актуальности. За последние несколько лет было выработано как минимум три подхода к решению этой задачи.
Метод #1
Первый, лежащий на поверхности метод заключается в корреляции и взаимном использовании результатов работы DAST и SAST. По идее, такой подход дает возможность расширить покрытие динамического анализа за счет результатов статического и снизить количество ложных срабатываний. По такому пути пошла компания IBM.
Вот как-то так работает метод
Однако вскоре стало понятно, что достоинства подобного подхода преувеличены. Передача дополнительных точек входа из SAST в DAST без понимания контекста (или дополнительных условий, если следовать нашей терминологии) зачастую приводит только к увеличению продолжительности работы. Представьте себе, что SAST обнаружил и передал в DAST 10000 комбинаций URL и параметров, но 9990 из них требует авторизации. Если SAST при этом не «объяснит» DAST, что авторизация нужна и как эту авторизацию проходить, то сканер будет бестолково стучаться по этим URL и время его работы увеличится в 1000 раз. Без особого изменения результата.
Но это не самое главное. Основной проблемой является несовместимость DAST и SAST по входу / выходу. Ведь в большинстве случаев на выходе статического анализатора вы получаете такую информацию: в строке 36 недостаточная фильтрация ввода, а значит возможна и реализация XSS. Для DAST же родным будет HTTP-запрос а-ля /path/api?parameter=[XSS]&topic=important с указанием типа уязвимости, и желательно, чтобы присутствовало множество значений для фаззера с учетом фильтрующих функций.
Где-то тут XSS… Надо передать ее в DAST! Но как?
Обратите внимание также на важный параметр topic=important. Это как-раз то условие, которое необходимо соблюсти, чтобы фаззер попал в нужный, уязвимый API. Ведь не факт, что уязвимость также присутствует в параметре при обращении к пути /path/api?parameter=[XSS]&topic=other. Откуда статический анализатор возьмет эту информацию? Неясно…
Сложностей добавляют различные модули а-ля mod_rewrite, а также фреймворки, настройки веб-сервера и прочие элементы, вносящие путаницу в.
Метод #2
Второй подход был связан с появлением в мире такого явления, как IAST (Interactive или даже Intrinsic Application Security Testing). По сути это расширение динамического анализа, заключающееся в трассировке выполнения серверной части приложения (в ходе фаззинга с использованием DAST). Для этого используется либо инструментация веб-сервера, фреймворка или исполняемого кода, либо встроенные механизмы трассировки.
Хранимая XSS и ее трассировка SpyFilter
Так, для поиска SQL Injection очень удобно использовать результаты SQL Server Profiler или схожие утилиты, где можно воочию увидеть, что же реально «долетело» до сервера через фильтрующие функции.
Похоже, я опять сделал немножко IAST…
После того как Dynamic Taint Analysis IAST в очередной раз пришел в индустрию AppSec, у него возникло множество адептов, превозносящих достоинства метода. К преимуществам можно отнести возможность увеличить эффективность динамического анализа путем отслеживания распространения запросов фаззера через разные уровни приложения, что позволяет минимизировать количество ложных срабатываний и отлавливать, например, Double Blind SQL Injection. Кроме того, инструментация на различных уровнях приложения дает возможность выявлять отложенные атаки, такие как Stored XSS или Second Order SQL Injection, перед которыми традиционно пасуют и SAST и DAST.
Важно, что метод позволяет решить задачу соответствия между точками входа приложения и сроками исходного кода (URL-to-source mappings). Все это непросто: и делается в три этапа, и сервер надо инструментировать — но как-то осуществляется.
Гибридный анализ. Взгляд HP (RAST=IAST)
Однако у IAST есть и недостатки. В первую очередь, необходимость инструментации кода и (или) установки агента для динамической инструментации веб-сервера (СУБД, фреймворков). Очевидно, что такая ситуация нежелательна для промышленных систем, и что могут возникнуть вопросы, когда речь пойдет о совместимости и производительности.
Кроме того, IAST в его текущем состоянии является расширением DAST (на что, кстати, явно указывает Gartner) и наследует не только положительные, но и отрицательные стороны этого метода. Ходят, конечно, слухи о чистом IAST, но это скорее к системам обнаружения вторжений и межсетевым экранам, которые могут и уязвимости выявлять при удачном стечении обстоятельств (о чем мы тоже скоро расскажем).
Возвращаемся к теме заметки. Использование в качестве промежуточного звена IAST позволяет отчасти решить проблему совместимости SAST и DAST — но лишь отчасти. Хотя в некоторых случаях (особенно при годном SAST) все может получится вполне неплохо.
Coverity + NTOSpider — better together!
Критика гибридного анализа приведена в докладе Криса Энга (A Dose of Reality on Hybrid Analysis, Chris Eng). Заметим, что многое из его отчета актуально и для простой корреляции результатов SAST и DAST, и для гибридного анализа с использованием IAST.
Метод #3
Видимая громоздкость подхода требует лучшего решения. И грядет появление такого решения, хотя еще неясно откуда. Для него пока не придумано соответствующее словечко, но в научных публикациях его аспекты встречаются все чаще и чаще. Суть его заключается в совмещении статического и динамического анализа без необходимости в промежуточном звене. То есть основа остается той же, но при этом статический анализ как потенциально более полный используется в качестве основного. Для решения этой задачи SAST должен иметь возможность подготавливать данные для верификации в понятном для DAST виде. Например, в формате HTTP-запроса с указанием необходимых дополнительных условий и множеством значений параметров для фаззинга. Можно так:
Эксплойт, бэкдор и два ствола дополнительное условие
Или так:
Тут Double Blind SQL Injection, нужна Time-Based...
Как этого достичь — тема отдельной заметки, но ничего невозможного здесь нет. Кстати, такой подход позволяет реализовать еще одну задачу — интеграцию SAST с Web Application Firewall, что весьма и весьма полезно для быстрого закрытия обнаруженных уязвимостей.
P. S. Чтобы не сложилось ложное впечатление, нужно отметить, что мы совсем не против IAST, а даже за. Некоторая резкость — это реакция на заявления типа: «I>S+D!» У этой технологии есть понятная ниша. Кроме того, метод позволяет реализовать концепцию непрерывного мониторинга, что нонче модно. Но для получения результатов, сходных с IAST, совершенно необязательно фаззить все приложение, а иногда нет необходимости его исполнять в прямом смысле этого слова. Но об этом, как уже было сказано, — позже.
Positive Technologies Application Inspector team
Автор: ptsecurity
