Фаззинг-тестирование: что это и как работает на практике

Фаззинг (fuzzing, fuzz testing) — метод динамического тестирования, с помощью которого проверяется готовое ПО или на финальной стадии разработки. В ходе проверки в работающую программу подаются специально сгенерированные или случайные входные данные. Цель — найти уязвимости, ошибки обработки ввода, утечки памяти и другие критичные моменты, которые не обнаружили раньше. 

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

Есть два типа фаззинга:

• Mutation-based (мутационный) — изменение корректных входных данных для создания новых тестовых.

• Generation-based (генерационный) — генерация наборов тестовых данных с нуля на основе спецификации протоколов и форматов для конкретного программного обеспечения. 

Мутационный подход (mutational fuzzing) берет корректные образцы входных данных (seed-файлы) и случайным образом изменяет их (переворачивает биты, вставляет/удаляет байты). Это быстро и не требует знаний о формате, но мутированные данные часто отбрасываются валидаторами программы на ранних этапах, не доходя до глубокой логики. 

Генерационный подход (generational fuzzing) создает входные данные с нуля на основе спецификации формата (например, грамматики протокола). Такие данные проходят валидацию и тестируют целевую логику, но требуют написания модели данных.

Эволюция фаззинга

Фаззинг зародился в 1988 году, когда профессор Бартон Миллер начал эксперименты с UNIX-утилитами, подавая на их вход случайный шум. Результаты этого исследования были впервые опубликованы в 1990 году в статье «Fuzz Testing of Application Reliability». Именно эта публикация считается отправной точкой в истории метода. Подход профессора стали развивать, чтобы выявлять сбои в приложениях.  

В 2000-х годах появился coverage-guided фaззинг, который позволял отслеживать, какие участки кода уже были покрыты тестированием и генерировать новые входные данные для анализа других участков. В этот период начали использовать фаззер American Fuzzy Lop (AFL). С его помощью удавалось обнаруживать уязвимости в открытом программном обеспечении, ядрах операционных систем и сетевых сервисах. 

Позднее начали развиваться инструменты для фаззинга промышленных систем и IoT, общедоступных библиотек программного кода. Такие анализаторы умеют обнаруживать уязвимости памяти, аварийные состояния ПО, корректность работы API-интерфейсов и другие проблемы, о которых разработчики могут даже не подозревать. 

Подходы к фаззингу

Различают три подхода к тестированию в зависимости от уровня доступа к исходному коду и осведомленности о структуре ПО:

• Black Box — метод, когда приложение является закрытым «черным ящиком». Доступа к исходному коду нет, понимания структуры и логики — тоже. Взаимодействие фаззера с приложением происходит через публичный интерфейс, обычно API или сетевой порт. Данные для тестирования являются полностью случайными или генерируются на основе предположений о формате входа. 

• White Box (фаззинг на основе символьного выполнения) — метод, при котором фаззер анализирует программу, используя технику символьного выполнения (symbolic execution). В отличие от Grey Box, где используется только обратная связь по покрытию кода, White Box фаззинг строит математические уравнения для каждого пути выполнения и решает их, чтобы сгенерировать входные данные, гарантированно проходящие по конкретным веткам кода. Это позволяет достичь более глубокого покрытия, но требует значительно больших вычислительных ресурсов. Классический White Box фаззинг требует доступа к исходному коду или его промежуточному представлению. Существуют также инструменты символьного выполнения, работающие непосредственно с бинарным кодом (например, SAGE), однако они относятся скорее к категории продвинутого анализа бинарных файлов.

• Grey Box — сочетание предыдущих подходов. Представление о внутреннем устройстве приложения есть, но полный анализ кода перед тестированием не проводится.  

С точки зрения эффективности подходов к фаззингу лидирует White Box, поскольку обеспечивает глубокое покрытие кода. Но этот метод требует сложной подготовки и значительных вычислительных ресурсов. Black Box применяется, если нет возможности получить доступ к коду, например, когда ПО наследованное или загружено из общедоступных источников. Grey Box подойдет, если нужно провести тестирование без сложного предварительного анализа. 

Разработчики и ИБ-команды используют для фаззинг-тестирования зрелые решения, которые интегрируются в CI/CD-процессы и поддерживаются активным сообществом. Примеры:

Фаззинг генерирует огромное количество данных: корпусы входных значений (seed-файлы), найденные сбои (crashes), минимизированные тест-кейсы и логи. Для эффективной командной работы все эти артефакты нужно версионировать и хранить централизованно. Особенно это актуально, если фаззинг используется в ML-проектах — например, при тестировании уязвимостей моделей или обработчиков данных.

Здесь пригодится Evolution Repo — облачный сервис для хранения репозиториев кода, ML-моделей и датасетов. Он поддерживает Git LFS для больших файлов, позволяет версионировать модели и датасеты, а также предоставляет API, совместимое с Hugging Face. В контексте фаззинга сервис удобно использовать для:

• хранения seed-корпусов и найденных сбоев в структурированном виде;

• версионирования тестовых датасетов, на которых запускается фаззинг;

• совместной работы команды над анализом результатов.

Интеграции с CI/CD процессами

Чтобы выявлять баги в программном обеспечении в ходе разработки, фаззинг часто включают в процессы непрерывной интеграции и доставки. В типовом CI-процессе собирается код с инструментированием, затем на ограниченное время (например, 10–30 минут) или с определенным количеством итераций запускается фаззер. 

Автоматические анализаторы для фаззинг-тестирования интегрируются с популярными системами автоматизации — Jenkins, GitLab CI/CD, GitHub Actions и другими. Анализ можно запускать при каждом pull request, в рамках nightly-сборок или security-пайплайнов.

Перед фаззингом подготовьте окружение и тестируемое программное обеспечение. Затем можно запускать инструмент для тестирования. Порядок действий на примере фаззера AFL++: 

1. Из официальных репозиториев установите AFL++ и зависимости.

2. Подготовьте исходный код, который будете тестировать. 

3. Скомпилируйте программу с инструментированием AFL++.

4. Определите точку входа для фаззинга, например, обработчик файлов, сетевой парсер или конкретная функция.

5. Запустите фаззер, укажите каталог входных данных и путь к тестируемой программе. 

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

Перед внедрением метода нужно понять, какие задачи он может решить, какие — нет.  Рассказываем о плюсах тестирования и минусах. 

Преимущества

Фаззинг — инструмент для поиска неожиданных проблем в работе программ. Его используют разработчики, инженеры ИБ, исследовательские организации. Популярность метода связана с такими преимуществами, как:

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

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

• Интеграция в CI/CD — тестирование можно встраивать в процессы непрерывной разработки, таким образом обеспечивая регулярный контроль безопасности ПО.

• Раннее выявление дефектов — с помощью фаззинга можно найти максимум проблем в работе ПО до релиза. 

• Поддержка различных типов ПО — можно тестировать серверные и клиентские приложения, библиотеки и протоколы.

Ограничения

Недостатки тестирования связаны с его реализацией и ограниченностью в областях применения. Типичные ограничения:

• Отсутствие гарантии полного покрытия кода — даже при методе White Box сложно обнаружить все уязвимости ПО. 

• Классический фаззинг (ориентированный на поиск сбоев) неэффективен для поиска логических ошибок, так как программа может работать без падений, но выдавать неверные результаты. Однако современные методы, такие как property-based testing и дифференциальный фаззинг, позволяют находить логические ошибки путем сравнения поведения с эталонной реализацией или проверки заданных инвариантов. Для эффективного поиска логических ошибок требуется не просто запустить фаззер, а написать специальные проверяющие функции (оракулы).

• Потребность в ресурсах — фаззинг-тестирование требует специальных инструментов и вычислительных мощностей. 

• Сложность воспроизведения — фаззер может найти баг, который трудно проанализировать при стандартных условиях эксплуатации ПО. 

Результаты фаззинг-тестирования зависят от грамотной интеграции в процессы разработки. Нужно применять этот метод в совокупности с другими, например, статическим анализом (Static Application Security Testing). 

Российские проекты и команды уже оценили практическую ценность фазинга и используют этот метод тестирования. Некоторые результаты:

Заключение

Фаззинг не заменяет другие методы оценки защищенности программного обеспечения, такие, как статическое тестирование и анализ состава ПО. Его стоит применять совместно с ними, чтобы всесторонне исследовать безопасность программ.  Для создания непрерывного цикла проверки кода и минимизации человеческого фактора фаззинг целесообразно интегрировать в CI/CD-процессы.