Разделы портала

Онлайн-тренинги

.
Про фаззинг замолвите слово…
27.10.2011 12:00

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

(Майкл Ховард)

Автор: Татьяна Зинченко

Прошла первая конференция ConfeT&QA, на которой я выступала с докладом про фаззинг. Очень много отзывов было примерно такого содержания: «Очень интересный доклад, но я совсем не знаю, что такое фаззинг».

Что же такое фаззинг и с чем его едят?

 

Фаззинг – это один из подвидов тестирования безопасности. Определений для него неимоверно много. Википедия определяет фаззинг как технологию тестирования программного обеспечения, когда вместо ожидаемых входных данных программе передаются случайные или специально сформированные данные. Т.е. программе чаще всего подсовываются заведомо неправильные данные, при этом отслеживаются такие ситуации, когда система не может их обработать и вылетает. Аварийное завершение работы считается нахождением дефекта в программе и может привести к дальнейшему выявлению уязвимости.

У нас этот вид тестирования еще не очень распространен, а на западе им пользуются уже достаточно давно. Еще в 1988 году Барт Миллер опубликовал работу The Fuzz Generator, в которой впервые был определен термин Fuzzing. А особо активное использование началось в 2006 году, когда при помощи фаззинга была найдена масса уязвимостей в Internet Explorer, Microsoft Word и Microsoft Excel. Сейчас фаззинг является одним из самых эффективных методов выявления проблем безопасности кода.

Выделяется три подхода к выявлению недостатков системы: тестирование методом черного, серого и белого ящиков. Различие между ними определяется теми ресурсами, которые доступны во время тестирования.

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

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

Одним из самых популярных на данный момент фаззеров для тестирования черного ящика является OWASP JBroFuzz. Он бесплатен, но при этом позволяет проводить самые различные проверки: на межсайтовый скриптинг (XSS), на SQL-инъекции, на переполнение буфера, целочисленное переполнение и пр. Он работает с самыми популярными сетевыми протоколами: HTTP, SOAP, XML, LDAP и др.

Метод серого ящика представляет собой комбинацию из метода черного ящика и восстановления кода (RCE – reverse code engineering). Сложно переоценить наличие исходного кода для тестирования безопасности, но даже если исходного кода нет – не все потеряно. Сходную картину можно получить при анализе скомпилированной сборки. Оценка безопасности сборки по отношению к уровню исходного кода называется бинарной проверкой.

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

Дизассемблеры преобразуют машинный код в ассемблерный, после чего его уже может читать человек.

Декомпиляторы статически анализируют и преобразуют двоичный код в такой формат, который понятен человеку. Т.е. они переводят код не в ассемблер, а в языковые конструкции более высокого уровня.

Дебаггеры запускают программу-объект или присоединяются к ней и отслеживают ее выполнение.

Дизассемблеры доступны как платные, так и бесплатные. К самым распространенным относятся инструменты компаний LogicLibrary, Veracode, Halvar Flake и др.

Метод белого ящика может применяться только в том случае, если доступен сам исходный код. Как и для метода черного ящика, проверка может выполняться вручную или с помощью инструментов. Но как и в черноящичном случае – проверка вручную трудоемкая и долгая.

Для проверки исходного кода используются на: средства проверки на этапе компиляции, браузеры исходного кода и автоматические инструменты проверки исходного кода.

Средства проверки на этапе компиляции обычно уже встроены в компиляторы и ищут недостатки после создания кода.

Браузеры исходного кода созданы для того, чтобы облегчать мануальный анализ кода.

Автоматические инструменты проверки исходного кода просматривают исходный код и определяют потенциальные уязвимости автоматически. Они бывают как платные, так и свободно распространяемые, но рассчитаны только на определенные языки программирования, поэтому если какой-то продукт написан на нескольких языках программирования – понадобится несколько инструментов. Или же не понадобится ни одного, если такой язык не поддерживается ни одним из существующих инструментов.

Одним из достаточно распространенных автоматических инструментов проверки исходного кода является RATS. Он бесплатен и может использоваться как для UNIX, так и для Win32. Он поддерживает C, C++, Perl, PHP и Python.

Не существует какого-то одного единственно верного подхода к нахождению уязвимостей в тестируемом приложении. Зачастую случается так, что несколько методов, инструментов дополняют друг друга, а не используются по отдельности.

Следует также помнить, что опытного тестировщика никогда не заменит ни один автоматический инструмент. Все подобные инструменты – только средства для облегчения тяжелого труда и сбережения массы времени. Но все создаваемые ими отчеты все равно должны проверяться опытными аналитиками, тестировщиками, разработчиками – или кто еще есть из опытных на проекте?

И последнее. Фаззинг – это не панацея от всех бед, и 100% результата он не гарантирует. Я помню несколько вопросов с примерным содержанием: «А зачем нам все это делать?» Ответить можно и так: «А вдруг именно вы будете тестировать тот интернет-банкинг, которым когда-нибудь буду пользоваться я?» Тестирование безопасности в общем, и фаззинг в частности, нужны нам для того, чтобы потом, в дальнейшем, после выпуска продукта на рынок не закрывать судорожно найденные злоумышленниками уязвимости, и не терять на этом десятки, а то и сотни тысяч каких-нибудь денег.

Обсудить в форуме