Черно-белая «статика» или динамический анализ исходных кодов

Краткое содержание: как модно искать уязвимости приложений; почему SAST и статический анализ, и DAST и динамический анализ не синонимы; в чем прелесть SAST и красота DAST; много скобок.



Немного о терминологии

Достаточно долгое время в анализе безопасности приложений параллельно существуют два направления: статический и динамический анализ. Зачастую их путают с методами «черного» (динамический анализ) и «белого» (статический анализ) ящика, но это не совсем верно. Так, например метод динамического анализа может применяться (и гораздо более эффективно) при наличии полного доступа к приложению и его исходным кодам. Распространено также заблуждение о эквивалентности анализа исходного кода и статического анализа, однако статический анализ может применятся и для скомпилированных приложений. Более того, в современном мире, где различные JIT технологии, такие как .NET MSIL и Java Bytecode - разница между анализом исходного кода и «скомпилированного» приложения достаточно условна.

Дополнительную сумятицу вносят аналитики, создавая маркетинговые категории, созвучные техническим названиям методов анализа. Так, у Gartner выделена категории Interactive Application Security Testing (IAST), которая по сути относится к динамическому анализу. При этом также существует Dynamic Application Security Testing (DAST) и Static Application Security Testing (SAST).
Однако, в реальном мире, при анализе эффективности различных продуктов, часто приходится сталкиваться с отчётами аналитиков, поэтому приходится использовать их терминологию. В связи с этим позволю себе ввести определения нескольких терминов:

• DAST – динамический (т.е. требующий выполнения) анализ безопасности приложения без доступа к исходному коду и среде исполнения серверной части.
• SAST – статический (т.е. не требующий выполнения) анализ безопасности приложения с доступом к исходному коду (или производным) приложения серверных и клиентских частей.
• IAST – динамический анализ безопасности приложения с доступом к исходному коду и среде исполнения серверной части.
• Анализ исходного кода – статический или динамический анализ с доступом к исходному коду (или производным) приложения серверных и клиентских частей.

Или, другими словами – DAST это динамический анализ методом «черного ящика» (по крайней мере для серверной части), SAST – статический анализ методом «белого ящика», и IAST (о котором я планирую написать отдельно) – динамический анализ методом «белого ящика».

DAST: хороший, плохой, злой

Динамический анализ приложений методом черного ящика самый простой и распространённый способ поиска уязвимостей. Собственно, каждый раз «вставляя кавычку в URL» или вводя '> мы осуществляем эту мудреную процедуру. По сути это fault injection (aka fuzzing) приложения, путем эмуляции клиентской части и попытки отправки на вход «хорошо известных плохих данных».
Простота метода приводит к большому количеству реализаций, и в «магическом квадранте» Gartner просто тесно от конкурентов. Более того, «движки» DAST присутствуют в большинстве систем контроля уязвимостей и соответствия стандартов, таких как MaxPatrol, за исключением разве что Symantec Control Compliance Suite. Распространены и некоммерческие решения, так базовый (очень-очень базовый) модуль DAST присутствует в Nessus, более продвинутые механизмы существуют в w3af или sqlmap.
К преимуществам DAST относится простота использования и отсутствие необходимости доступа к серверной части приложения. Также серьезным плюсом является относительная независимость от платформы, фреймворков и языков, на которых разработано приложение. Учет этих нюансов может повысить эффективность анализа, но это скорее оптимизация, добавляющая проценты к общей эффективности.

Однако у DAST есть и обратная сторона. Перечислим списком:

• Невысокая степень покрытия. Далеко не все вызовы API и точки входа можно легко обнаружить методом черного ящика.

Старая, но субъективно верная картинка

• Драматическое падение эффективности при усложнении клиента/протокола. Приложения Web 2.0, JSON, Flash, HTML 5.0 и JavaScript требует либо динамического (например, эмуляцией выполнения JavaScript) либо статического разбора («отгрепать» Flash или taint-анализ того же JavaScript) клиентской части, что значительно усложняет клиентскую часть фазера, приближая его к «полноценному» браузеру.
• Ненулевая вероятность нарушения целостности и доступности (например при попадании конструкций типа or 1=1 в UPDATE через SQL Injection). 
• Долгое время работы. Вашему покорному слуге практически ни разу не удавалось наблюдать завершения работы большинства из утилит класса DAST на достаточно «разлапистом» сайте, раньше заканчивалось окно на тестирование. Тут хорошо подходит правило Парето – за 20% времени найти 80% уязвимостей.
• Сложность выявления многих типов. Например, ошибки использования криптографии, такие как слабые механизмы генерации cookie или session ID (кроме самых примитивных случаев) DAST обнаруживает крайне плохо. 

SAST: Quick and dirty

Внезапно, я расскажу о недостатках SAST. Прежде всего – отсутствие единого инженерного или научного подхода (вызванное, впрочем, объективными трудностями) приводит к тому, что каждый из разработчиков копает что-то сам, а маркетологи облекают это в глянцевые псевдонаучные обертки, что вызывает праведное возмущение.
Многие из методов статического анализа генерируют большое количество «подозрений на уязвимость», которые на проверку оказываются ложными срабатываниями, что существенно увеличивает трудозатраты.

Всего-то 1600+ XSS и 18 000+ ошибок конфигурации. Наглядная демонстрация «полноты анализа»?

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

Собственно «статичность». Примеров тут множество, и генерируемый «на лету» код, и хранение кода/данных в СУБД, файловой системе и т.д. Отдельных трудозатрат разработчикам добавляет зависимость от языков (и даже версий), фреймворков. Так, чтобы понять точки входа и точки выхода, фильтрующие функции недостаточно понимания «голого» языка, необходимо распознавать те библиотеки и фреймворки, которые используют разработчики в реальном мире.

Хороший пример. И динамические инклуды и легко читаемая инициализация приложения.

Если бы губы Никанора Ивановича...

И у SAST и DAST есть свои преимущества и недостатки и достаточно долгое время муссируется идея об объединении результатов работы этих методов или о «гибридном анализе» (hybrid analysis), что позволит взять лучшее из этих двух подходов. Не смотря, на то, что данная гипотеза, что называется «лежит на поверхности» и относится к интуитивно понятным, реализация данной концепции на практике не дает ожидаемых результатов. Но об этом позже.

PS.Дополнительно хочу отослать с заметкам [1] и [2] Андрея Петухова.