Маркетинг @ Анализаторы исходного кода

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

Так как я человек впечатлительный и легко поддающийся на троллинг, решил написать своё ответное мнение в серии постов на тему «Типичный булшит в якобы аналитических заметках про технологии анализа исходного кода».

Итак, сегодня — первая серия, и поговорим мы вот про какие заявления (встречаются в произвольной комбинации): «сигнатурный анализ не может обеспечить полноту», «сигнатурный анализ дает много ложных срабатываний», «сигнатурный анализ хуже, чем анализ потоков данных», «анализ потоков данных дает офигительную полноту при низком числе ложных срабатываний», «о какой полноте может идти речь при наличии в базе N сигнатур» и вот это вот всё.

Для тех, кто испугался объема, сразу выводы:

1. Все применяемые сейчас вида анализа кода — сигнатурные (в т.ч. taint анализ на основе потоков данных).

2. В свете п.1. сравнивать подходы и продукты по количеству сигнатур — нонсенс. Сигнатура может описывать как целый класс недостатков (например, input validation), так и один-единственный экземпляр (unserialize($_GET[.*])).

3. Про полноту и точность можно говорить только после фиксирования класса недостатков (например, input validation). Полноты «вообще» — не существует. В свете разговора про каждый класс недостатков на первое место выходит формальная модель описания недостатка. По факту, сейчас почти всегда используется модель невмешательства (aka taint). Данная модель описывает только уязвимости класса input validation. Она бесполезна для недостатков авторизации. Полнота, говорите?

4. Даже в рамках одного класса недостатков, например, input validation, существующая модель невмешательства не может обеспечить не только полноту, но и даже приемлемую точность. Ограничения модели невмешательства расписаны вот тут (англ).

Наука, инновации, статический анализ и РусКрипто 2013

В этом году на горячо любимой мной конференции РусКрипто впервые за ее историю состоится отдельная секция по анализу кода — «Анализ кода и технологии защиты: динамический и статистический анализ, виртуализация кода, исследование на недекларированные возможности».

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

А вот и расширенная аннотация моего доклада.

Инструменты для обнаружения DOM-based XSS

Не могу не поделиться новостью о выходе еще одного инструмента для обнаружения DOM-based XSS, в этот раз от Stefano Di Paola из Minded Security.
До этого момента мне был знаком только один исправно работающий инструмент, находящий DOM-based XSS — это IBM AppScan, который применяет статический taint-анализ JavaScript’а.
Вроде бы еще Тарас рассказывал о модуле для w3af, который предназначен для той же цели. Возможно, он оставит более подробный комментарий.
И вот теперь вышел инструмент DOMinator, который использует динамический анализ JavaScript’а. Очень любопытно, как он себя покажет в деле (пока руки не дошли попробовать). Скачать бета-версию можно отсюда.

Taint Analysis: ограничения модели. Часть 1.

Недавно мы рассмотрели две модели уязвимостей, которые используются при статическом и динамическом анализе веб-приложений. В предыдущем посте было показано, что обнаружение уязвимостей не будет эффективно на 100%, если у используемой модели есть ограничения. Именно об ограничениях taint-анализа и пойдет сегодня речь. Мы рассмотрим, какие типы уязвимостей заведомо не могут быть найдены при использовании этой модели.

Обнаружение уязвимостей: рассуждение о полноте и точности

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

Модели уязвимостей, используемые в статическом и динамическом анализе

В предыдущем посте я вкратце рассказал об особенностях статического и динамического анализа в контексте проверки свойств программы. Одно из возможных свойств — это наличие или отсутствие уязвимостей¹.
Возникает вопрос, как переформулировать классическое определение уязвимости (свойство, позволяющее нарушить конфиденциальность, целостность или доступность информационных ресурсов ) в терминах представлений программы (см. предыдущий пост)? Давайте попробуем разобраться.

Статический vs динамический анализ

Так получилось, что в течение буквально двух недель я натолкнулся на несколько упоминаний статического анализа в контексте поиска уязвимостей веб-приложений. Некоторые из этих суждений я немедленно хотел уточнить/поправить. Это навело меня на мысль, что хорошо было бы рассказать «на пальцах», что есть статический и динамический анализ, и как это все можно применить к анализу безопасности веб-приложений.
Итак, эту серию постов я начну с рассказа о том, что же вообще из себя представляет статический и динамический анализ.