Довелось сегодня выступать на мероприятии под названием "
Российские интернет-технологии 2010" (сокр. РИТ++) по теме "
Анализ защищенности интернет-проектов". Презентация с выступления представлена ниже.
И скромный фото-отчет с мероприятия доступен
здесь.
в тему: Уязвимость в WordPress стала причиной взлома сотен блогов
ОтветитьУдалить> в тему: Уязвимость в WordPress стала причиной взлома сотен блогов
ОтветитьУдалитьупс... )
p.s. Кстати, если тебе интересен feed back по презентации, у меня есть что сказать по поводу статического und динамического анализа
да, интересен
ОтветитьУдалитьНе дает все запостить сразу, поэтому по частям...
ОтветитьУдалитьДело в том, что статическим анализатором люди называют все, что анализирует исходный код (даже grep :))
Если смотреть глубже, то есть несколько типов статического анализа:
- сигнатурный
- основанный на моделях уязвимостей
- верификация
Сигнатурный метод самый простой. Мы переводим программу в промежуточное представление (например, CFG) и ищем "плохие" конструкции. Так, например, работает RATS. Тут ты правильно написал фундаментальное ограничение.
Однако большинство коммерческих статических анализаторов работают по-другому. Они тоже переводят программу во внутреннее представление (CFG + зависимости по данным). Отличия начинаются далее. Есть общепринятые модели уязвимостей в терминах этих самых внутренних представлений программы (например, в терминах зависимостей). Вот анализаторы берут и проверяют, удовлетворяет ли граф программы требованиям модели. Если да - нашли уязвимость, если нет - всё оке. Простейшая модель уязвимости - это наличие зависимости по данным аргументов критических операций (например, mysql_query) от пользовательского ввода (например, $_GET['arg']) без фильтрации (например, addslashes) - то есть банальный поиск пути в графе.
Про верификацию не буду :)
Теперь по поводу бонусов, которые дает статический анализ. Мы имеем исходный код, а значит видим все пути выполнения программы. А это значит, что он мы можем провести полный консервативный анализ: если он скажет, что уязвимостей нет, значит их нет на самом деле. (например, пометить все вызовы mysql_query уязвимыми, хыхы) Плата за это - большое число ложных срабатываний из-за фундаментальных ограничений статического анализа (см. Теорема Райса). Если на пальцах, то во время статического анализа мы должны делать предположения (например, сколько итераций будет в цикле, какова глубина рекурсии, каково содержимое контейнеров типа списков и хэш-таблиц), которые и влияют на точность анализа.
ОтветитьУдалитьВ динамическом анализе используются те же модели уязвимостей, что и в статическом анализе (например, распространение метки taint - это всего лишь способ определения зависимостей по данным). Разница в том, что мы рассматриваем конкретный путь выполнения с конкретными входными данными. А значит, мы знаем все значения переменных в каждой точке программы. Отсюда точность анализа (нет false positive) и его неполнота - уязвимости могут проявляться на других путях выполнения при других исходных данных. А создание полного тестового покрытия - увы тоже неразрешимая задача :)
В качестве резюме: в статическом и динамическом анализе используются одни и те же модели уязвимостей. Плюсы и минусы следуют из самого подхода - либо мы выбираем полноту и платим за это точностью, либо наоборот, выбираем точность и платим за это полнотой.
ОтветитьУдалитьp.s. ну по мелочи - ты перепутал ошибки первого и второго рода :) (http://ru.wikipedia.org/wiki/Ошибки_первого_и_второго_рода)
спасибо за полезный и подробный комментарий! :)
ОтветитьУдалитьИменно поентому все продвинутые пацаны идут по пути комбинации статики с динамикой или на худой конец - fault injection. Чтобы стало-быть уточнять и вешать вероятности наличия уявзвимости и все такое.
ОтветитьУдалитьКстати, не соглашусь с коллегой по поводу "нет false positive" в динамике. Классический пример - XSS. Где критерии "наличия уязвимости" очень меняются от браузера/версии. Ужесточишь критерии - и все - половину багов не видишь.
ЗЫ. https://365.rsaconference.com/blogs/podcast-series-rsa-conference-2010/2010/02/03/and-302-best-of-both-worlds-correlating-static-and-dynamic-analysis-results
В любом случае весь статический анализ упрётся в проблему останова, в общем случае :)
ОтветитьУдалить> Кстати, не соглашусь с коллегой по поводу "нет false positive" в динамике.
ОтветитьУдалитьGood point. Я имел в виду, что нет false positive в терминах проверки свойств модели - ибо она построена точно. Ограничения модели (но это проблема модели) - да, дают ложные срабатывания. Например, если мы в tainted mode делаем фильтрацию через ветвление:
input = get_HTTP_param(‘username’)
if (input.contains(’badchars’)) {
// return error page
// if we untaint variable input, then we could get an XSS in the first branch
} else {
// do processing
// if we do not untaint then we could get a false positive at the sink in the second branch
}
Эту проблему можно решить, добавив анализ строк, но это уже выход за пределы модели. Напомню, в модели у нас есть фильтрующие функции, которые возвращают "хорошие" данные во всех путях )
> false positive в терминах проверки свойств модели - ибо она построена точно
ОтветитьУдалитьЛюблю "научных" людей!