Скрестить ужа с ежом. Найти все-все 0-day. Захватить Вселенную!11

Краткое содержание

1. Несовместимость DAST / SAST.
2. IAST: Buzzword и реальность.
3. Третий путь.

Как мы отмечали ранее ^[1], у систем поиска уязвимостей SAST и DAST есть как преимущества, так и недостатки, поэтому проблема поиска оптимального подхода к автоматизации анализа безопасности приложений не теряет своей актуальности. За последние несколько лет было выработано как минимум три подхода к решению этой задачи.

Метод #1

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

Вот как-то так работает ^[2] метод

Однако вскоре стало понятно, что достоинства подобного подхода преувеличены. Передача дополнительных точек входа из 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 ^[3], а также фреймворки, настройки веб-сервера и прочие элементы, вносящие путаницу в.

Метод #2

Второй подход был связан с появлением в мире такого явления, как IAST (Interactive или даже Intrinsic Application Security Testing). По сути это расширение динамического анализа, заключающееся в трассировке выполнения серверной части приложения (в ходе фаззинга с использованием DAST). Для этого используется либо инструментация веб-сервера, фреймворка или исполняемого кода, либо встроенные механизмы трассировки.

Хранимая XSS и ее трассировка SpyFilter ^[4]

Так, для поиска SQL Injection очень удобно использовать результаты SQL Server Profiler или схожие утилиты, где можно воочию увидеть, что же реально «долетело» до сервера через фильтрующие функции.

Похоже, я опять сделал ^[5] немножко 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 ^[6]) и наследует не только положительные, но и отрицательные стороны ^[7] этого метода. Ходят, конечно, слухи о чистом IAST ^[8], но это скорее к системам обнаружения вторжений и межсетевым экранам, которые могут и уязвимости выявлять при удачном стечении обстоятельств (о чем мы тоже скоро расскажем).

Возвращаемся к теме заметки. Использование в качестве промежуточного звена IAST позволяет отчасти решить проблему совместимости SAST и DAST — но лишь отчасти. Хотя в некоторых случаях (особенно при годном SAST) все может получится вполне неплохо.

Coverity + NTOSpider — better together!

Критика гибридного анализа приведена в докладе Криса Энга (A Dose of Reality on Hybrid Analysis, Chris Eng) ^[9]. Заметим, что многое из его отчета актуально и для простой корреляции результатов SAST и DAST, и для гибридного анализа с использованием IAST.

Метод #3

Видимая громоздкость подхода требует лучшего решения. И грядет появление такого решения, хотя еще неясно откуда. Для него пока не придумано соответствующее словечко, но в научных публикациях его аспекты встречаются все чаще и чаще. Суть его заключается в совмещении статического и динамического анализа без необходимости в промежуточном звене. То есть основа остается той же, но при этом статический анализ как потенциально более полный используется в качестве основного. Для решения этой задачи SAST должен иметь возможность подготавливать данные для верификации в понятном для DAST виде. Например, в формате HTTP-запроса с указанием необходимых дополнительных условий и множеством значений параметров для фаззинга. Можно так:

Эксплойт, бэкдор ^[10] и два ствола дополнительное условие

Или так:

Тут Double Blind SQL Injection, нужна Time-Based...

Как этого достичь — тема отдельной заметки, но ничего невозможного здесь нет. Кстати, такой подход позволяет реализовать еще одну задачу — интеграцию SAST с Web Application Firewall, что весьма и весьма полезно для быстрого закрытия обнаруженных уязвимостей.

P. S. Чтобы не сложилось ложное впечатление, нужно отметить, что мы совсем не против IAST, а даже за. Некоторая резкость — это реакция на заявления типа: «I>S+D!» У этой технологии есть понятная ниша. Кроме того, метод позволяет реализовать концепцию непрерывного мониторинга, что нонче модно. Но для получения результатов, сходных с IAST, совершенно необязательно фаззить все приложение, а иногда нет необходимости его исполнять в прямом смысле этого слова. Но об этом, как уже было сказано, — позже.

Positive Technologies Application Inspector ^[11] team

Автор: ptsecurity

Источник ^[12]