За последний год я прогнал AFL++ через парсеры JSON и XML в трёх open-source веб-фреймворках. Результат: два heap-buffer-overflow и один use-after-free - все три в коде, который обрабатывает входные данные от пользователя. Ни один из этих багов не нашли юнит-тесты, статический анализ или ручной code review. Ноль из трёх. Фаззинг веб-приложений и API - это не «запустил ffuf по словарю и посмотрел коды ответов». Это coverage-guided процесс, где фаззер видит внутреннюю структуру кода, мутирует входные данные на основе покрытия и целенаправленно лезет в необработанные ветки. Разница между black-box фаззингом через HTTP и coverage-guided подходом на уровне исходников - как между стуком по стене в надежде услышать пустоту и рентгеном конструкции.
Место фаззинга в цепочке атаки
Фаззинг - инструмент фаз reconnaissance и resource development по MITRE ATT&CK. Vulnerability Scanning (T1595.002, Reconnaissance) - автоматизированный поиск слабых мест в публично доступных приложениях. Найденный через фаззинг баг превращается в эксплойт - Exploits (T1587.004, Resource Development), - который идёт в ход для Exploit Public-Facing Application (T1190, Initial Access).На конкретном пентесте цепочка выглядит так:
- Сбор информации - определяем стек целевого приложения: язык, фреймворк, нативные парсеры, используемые библиотеки
- Написание harness - создаём обёртку, которая подаёт фаззеру данные в формате, ожидаемом целевым парсером
- Фаззинг с санитайзерами - запуск AFL++ или LibFuzzer с AddressSanitizer, сбор крашей
- Triage - анализ крашей, определение root cause, оценка exploitability
- Exploit development - если баг эксплуатируемый, собираем PoC
- Применение - на пентесте, в bug bounty или CVE-репорт
Black-box vs coverage-guided fuzzing: выбор подхода
Прежде чем хвататься за конкретные инструменты - определитесь с подходом. Выбор зависит от двух вещей: есть ли исходный код и что за цель.| Условие | Подход | Инструмент | Что найдёте |
|---|---|---|---|
| Есть исходники на C/C++/Rust | Coverage-guided (grey box) | AFL++, LibFuzzer | memory corruption, use-after-free, heap overflow |
| Есть исходники на Python | Coverage-guided (grey box) | Atheris + LibFuzzer backend | unhandled exceptions, ReDoS, type confusion |
| Есть исходники на Go | Coverage-guided (grey box) | go test -fuzz (встроенный) | panic, index out of range, nil dereference |
| Нет исходников, есть OpenAPI/Swagger spec | Stateful API fuzzing (black box) | RESTler, Schemathesis | 500-ошибки, injection, auth bypass |
| Нет исходников, нет спецификации | Blind API fuzzing (black box) | ffuf, wfuzz, Burp Intruder | injection, path traversal, parameter pollution |
| Нет исходников, кастомный протокол | Stateful protocol fuzzing | Boofuzz | crash, memory corruption через протокол |
Ключевое ограничение black-box подхода: фаззинг через HTTP-запросы практически никогда не находит memory corruption в серверном коде. WAF или сам веб-сервер отбросит malformed request до того, как данные дойдут до уязвимого парсера. Coverage-guided подход работает на уровне функции - данные попадают напрямую в целевой код, минуя все промежуточные слои.
По данным обзора Dharmaadi et al. (2024, arxiv) - пожалуй, самого полного survey по фаззингу серверных веб-приложений - основная проблема web API фаззинга в том, что HTTP-запросы должны быть валидными, иначе веб-сервер их отвергает на ранней стадии. Это фундаментальное отличие от бинарного фаззинга, где можно подать произвольный мусор на stdin. Тот же обзор указывает на «ineffectiveness of instrumentation» как одну из ключевых нерешённых проблем - инструментировать серверное веб-приложение технически сложнее, чем скомпилированный бинарь.
Когда coverage-guided подход неприменим: внешний пентест SaaS без доступа к исходникам или бинарям; тестирование cloud-native API через публичные эндпоинты; аудит legacy-систем, где пересборка невозможна (нет исходников, нет build-системы). Тут - только black-box.
AFL++ для веб-компонентов: harness как фундамент
Требования к окружению
- ОС: Linux (Ubuntu 22.04+ или Debian 12+), macOS частично (без persistent mode некоторых фич)
- RAM: минимум 4 ГБ, рекомендуется 8+ ГБ при запуске параллельных инстансов
- AFL++ 4.x (репозиторий активно поддерживается, коммиты еженедельно)
- Компиляторы: clang/LLVM 14+ для инструментации LTO
- AddressSanitizer входит в LLVM, отдельная установка не требуется
- Сетевые требования: полностью offline-совместим, всё работает локально
Что фаззить в веб-приложении
Веб-приложение - не монолит. Это набор парсеров, сериализаторов и обработчиков, каждый из которых принимает недоверенные данные. Самые продуктивные цели для coverage-guided фаззинга уязвимостей:- Парсеры форматов: JSON, XML, YAML, protobuf, MessagePack. Категория A08:2021 (Software and Data Integrity Failures) по OWASP прямо указывает на insecure deserialization как критический риск
- HTTP-парсеры: обработка заголовков, multipart form-data, chunked encoding. Часто написаны на C/C++ даже в Python/Node.js стеках - через нативные расширения
- Обработчики загрузки файлов: парсинг изображений (libpng, libjpeg), PDF, XLSX - классика для mutation-based fuzzing
- Валидаторы: regex-движки (ReDoS, CWE-1333), email-парсеры, URL-парсеры, кастомные DSL
- Криптографические операции: верификация подписей, парсинг сертификатов (ASN.1), JWT-обработка
Harness: анатомия обёртки для веб-парсеров
Harness - функция, которая принимает сырые байты от фаззера и передаёт их в целевой код. От качества harness зависит, найдёт фаззер баги за 20 минут или будет гонять впустую сутки. Я видел ситуацию, когда два harness для одной библиотеки - один написан за 10 минут, второй за 2 часа с анализом реальных вызовов - давали разницу в coverage 4x за первый час.Harness для AFL++ должен: читать данные через shared memory (или stdin), вызывать целевую функцию и не делать лишних I/O-операций (сеть, диск замедляют фаззинг на порядки).
C:
// harness_json.c - пример для демонстрации концепции
#include <stdio.h>
#include <stdlib.h>
#include "target_json_parser.h"
__AFL_FUZZ_INIT();
int main(void) {
__AFL_INIT();
unsigned char *buf = __AFL_FUZZ_TESTCASE_BUF;
while (__AFL_LOOP(10000)) {
int len = __AFL_FUZZ_TESTCASE_LEN;
json_parse(buf, len);
}
}[B]AFL_LOOP(10000) - persistent mode: процесс переиспользуется вместо fork-exec на каждый тест-кейс. Прирост скорости в 10-20 раз. [/B]AFL_FUZZ_TESTCASE_BUF - shared memory, ещё быстрее чтения из stdin.Компиляция с инструментацией и AddressSanitizer:
AFL_USE_ASAN=1 AFL_USE_UBSAN=1 afl-clang-lto -o harness harness_json.c -ltarget_json. AFL_USE_ASAN=1 активирует ASan, который ловит heap-buffer-overflow, use-after-free, stack-buffer-overflow, double-free. Без ASan фаззер увидит только hard crash (SIGSEGV/SIGABRT), а тонкие memory corruption проскочат незамеченными.Запуск:
afl-fuzz -i corpus/ -o findings/ -m none -- ./harness. Каталог corpus/ должен содержать seed-файлы - минимальные валидные примеры. Для JSON: {"key":"value"}, [], "", 0, null. Разнообразный seed corpus ускоряет выход фаззера к глубоким веткам кода.CmpLog: решение проблемы магических байтов
Стандартный coverage-guided фаззинг плохо справляется с условиями видаif (header == 0xDEADBEEF) - вероятность угадать 4 байта мутацией ничтожна. AFL++ решает это через CmpLog (аналог RedQueen): инструментирует сравнения и подставляет значения из правой части условия в corpus. Для веб-парсеров это критично - XML начинается с <?xml, JSON-схемы содержат обязательные ключи, HTTP-заголовки имеют фиксированный синтаксис.Подключение: собрать два бинаря. Основной с ASan:
AFL_USE_ASAN=1 afl-clang-lto -o harness harness_json.c -ltarget_json. Вспомогательный CmpLog без ASan (совмещение ASan+CmpLog не рекомендуется из-за overhead): AFL_LLVM_CMPLOG=1 afl-clang-lto -o harness.cmplog harness_json.c -ltarget_json. Запуск: afl-fuzz -i corpus/ -o findings/ -c ./harness.cmplog -- ./harness. CmpLog заметно ускоряет прохождение парсеров с жёсткой структурой входных данных.Ограничения AFL++ фаззинга в веб-контексте
- Требует перекомпиляции целевого кода - не подходит для SaaS без доступа к исходникам
- Для интерпретируемых языков (Python, Ruby, PHP) нужны специализированные обёртки
- Persistent mode не всегда корректен: если целевая функция использует глобальное состояние, которое не сбрасывается между итерациями, появляются false positives
- Не видит логических багов (IDOR, auth bypass) - только memory corruption и crash
LibFuzzer: быстрый in-process поиск уязвимостей
LibFuzzer - in-process coverage-guided фаззер, встроенный в LLVM. В отличие от AFL++, работает внутри одного процесса без fork - быстрее для фаззинга отдельных функций, но менее устойчив: один crash завершает сессию.Применимость для веб-приложений: LibFuzzer идеален для фаззинга нативных расширений. Если Python/Node.js приложение использует C-библиотеку для парсинга (libxml2, rapidjson, zlib, openssl - а используют практически все), LibFuzzer фаззит именно этот нативный слой.
C:
// fuzz_xml.c - harness для libxml2
#include <libxml/parser.h>
int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
xmlDocPtr doc = xmlReadMemory(
(const char *)data, size, "noname.xml", NULL, 0);
if (doc != NULL) xmlFreeDoc(doc);
xmlCleanupParser();
return 0;
}clang -g -fsanitize=fuzzer,address -o fuzz_xml fuzz_xml.c $(xml2-config --cflags --libs). Запуск: ./fuzz_xml corpus_xml/ -max_len=65536 -jobs=4. Параметр -jobs=4 запускает четыре параллельных процесса - утилизация многоядерной машины.AFL++ vs LibFuzzer для фаззинга веб-приложений: AFL++ устойчивее для длительных кампаний (дни, недели) - crash не убивает весь процесс. LibFuzzer быстрее для коротких сессий и проще интегрируется в CI/CD (один бинарь, без внешних зависимостей). На практике для серьёзного поиска 0-day уязвимостей я запускаю оба: LibFuzzer - быстрый первый проход, AFL++ - длительная кампания с расширенными мутационными стратегиями (MOpt, CmpLog).
Atheris: фаззинг Python-компонентов REST API
Значительная часть современных веб-приложений написана на Python, JavaScript или Go. Фаззить их AFL++ напрямую нельзя - нет нативного бинаря для инструментации. Для Python есть Atheris - coverage-guided фаззер от Google, работающий на базе LibFuzzer.Atheris перехватывает coverage на уровне CPython bytecode. Где это полезно:
- Django/Flask/FastAPI view-функции, обрабатывающие пользовательский ввод
- Пользовательские валидаторы и сериализаторы в REST API
- Парсеры специфических форматов (CSV с кастомной логикой, проприетарные протоколы поверх HTTP)
Python:
# fuzz_api_validator.py - пример для демонстрации концепции
import atheris, sys
from myapp.validators import parse_user_input
def TestOneInput(data):
try:
parse_user_input(data.decode("utf-8", errors="ignore"))
except (ValueError, KeyError):
pass # ожидаемые исключения пропускаем
atheris.Setup(sys.argv, TestOneInput)
atheris.Fuzz()python fuzz_api_validator.py -max_len=4096 corpus/. Atheris найдёт unhandled exceptions, бесконечные циклы (timeout), excessive memory allocation - потенциальные DoS-вектора (Endpoint Denial of Service, T1499 по MITRE ATT&CK; для resource exhaustion через ReDoS/memory - T1499.004, Application or System Exploitation).Ограничение по скорости: Atheris выдаёт 100-1000 exec/sec вместо 10000-100000 у AFL++/LibFuzzer на нативном коде. Для глубокого поиска memory corruption в нативных расширениях Python-пакетов (Pillow, lxml, cryptography) Atheris требует пересборки C-кода с LibFuzzer-инструментацией (
atheris_no_libfuzzer_main), что по сути эквивалентно прямому использованию LibFuzzer на C-слое. Atheris - про логику Python-кода, а не про memory bugs.Фаззинг REST API: от спецификации к серверным крашам
Coverage-guided подход требует доступа к коду. На внешнем пентесте, когда доступны только HTTP-эндпоинты, работает stateful API fuzzing - генерация последовательностей HTTP-запросов на основе OpenAPI/Swagger спецификации.Инструменты API fuzzing: trade-off
| Критерий | RESTler (Microsoft) | Schemathesis | ffuf/wfuzz | Boofuzz |
|---|---|---|---|---|
| Подход | Stateful, grammar-based | Property-based, Hypothesis | Wordlist-based, black box | Stateful protocol |
| Когда использовать | Есть OpenAPI spec, нужны цепочки запросов | Есть OpenAPI/GraphQL spec, проверка контрактов | Нет спецификации, фаззинг параметров | Кастомные протоколы, не HTTP |
| Когда НЕ использовать | Нет спецификации | Таргетированный поиск конкретных CWE | Stateful сценарии, memory corruption | Стандартные REST API |
| Статус | Активный (Microsoft Research) | Активный, частые релизы | Активный, широко используется | Активный, нишевый |
Тот же survey Dharmaadi et al. (2024) показывает: большинство web API фаззеров используют OpenAPI спецификацию для генерации шаблонов запросов. Это решает проблему валидности HTTP - серверы отвергают невалидные запросы. Но у подхода серьёзный gap: спецификация описывает только документированные эндпоинты. Скрытые API, debug-маршруты, internal-эндпоинты остаются вне зоны покрытия.
Как я делаю на внешнем пентесте: сначала
ffuf -u https://target/FUZZ -w api-wordlist.txt -mc 200,301,403 для обнаружения скрытых эндпоинтов, затем RESTler или Schemathesis для глубокого stateful фаззинга по найденным и документированным маршрутам.В контексте OWASP A03:2021 (Injection) API фаззинг находит SQL injection, NoSQL injection, OS command injection через мутацию параметров. Но ещё ценнее - логические баги: race conditions при параллельных запросах, IDOR через перебор идентификаторов, нарушения бизнес-логики при нестандартных последовательностях вызовов.
Санитайзеры и триаж крашей
Найти crash - половина дела. Вторая - понять, эксплуатируемый ли это баг и какой CWE ему соответствует.Интеграция фаззинга в CI/CD: автоматизированный поиск уязвимостей
Фаззинг приносит максимум пользы при непрерывной работе, а не при однократном запуске. Один прогон - лотерея. Регулярные прогоны - статистика.Corpus-based fuzzing в пайплайне
Минимальная CI-схема для фаззинга бинарных приложений и веб-компонентов:- На каждый PR - короткий прогон (10-30 минут) с regression corpus. Цель: проверить, что новый код не создал регрессию по ранее найденным крашам
- Nightly - длительная кампания (4-8 часов) с расширенными мутациями (MOpt, CmpLog). Цель: поиск новых багов
- Weekly - полный фаззинг с обновлённым corpus (добавляются seed из реальных API-запросов)
Управление corpus
Corpus - то, что отличает результативный фаззинг от бесполезного шума:- Seed из production логов: реальные HTTP-запросы к API (с обфусцированными credentials) - лучший starting corpus для фаззинга REST API
- Минимизация:
afl-cmin -i corpus/ -o corpus_min/ -- ./harnessдля AFL++,./fuzz_target -merge=1 corpus_merged corpus_rawдля LibFuzzer - убирает дубликаты по coverage - Версионирование: corpus хранится в Git LFS или артефактах CI. Потеря corpus между прогонами = потеря недель работы фаззера
- Ручное обогащение: пустые строки, максимально длинный input, unicode, null bytes, boundary values. Для веб-контекста: невалидный Content-Type, nested JSON глубиной 100+, multipart с миллионом boundaries
Сводная таблица подходов к фаззингу веб-приложений
| Критерий | AFL++ | LibFuzzer | Atheris | RESTler |
|---|---|---|---|---|
| Скорость (exec/sec) | 1K-50K | 5K-100K | 100-1K | 10-100 |
| Типы багов | memory corruption | memory corruption | exceptions, DoS | injection, auth bypass, 500 |
| Требует исходников | Да (C/C++/Rust) | Да (C/C++) | Да (Python) | Нет (нужен OpenAPI) |
| Ловит memory corruption | Да | Да | Только в C-расширениях | Нет |
| CI/CD интеграция | Средняя (Docker) | Высокая (один бинарь) | Высокая (pip) | Средняя |
| Длительные кампании | Да (устойчив к крашам) | Ограниченно (-jobs смягчает, но crash завершает процесс) | Частично | Да |
| Поддержка CmpLog/dictionary | Да (CmpLog, RedQueen) | Да (dictionaries) | Нет | Грамматика из spec |
| Когда НЕ использовать | Нет исходников | Длительные кампании | Нативный C/C++ | Кастомные протоколы |
От crash к CVE: workflow поиска 0-day уязвимостей
Crash в open-source библиотеке - потенциальный 0-day, если библиотека используется в production веб-приложениях. Процесс:- Верификация - подтвердить crash на последней стабильной версии
- Root cause analysis - определить CWE. Heap-buffer-overflow: CWE-122. Use-after-free: CWE-416. Null dereference: CWE-476. Integer overflow: CWE-190
- Exploitability - WRITE примитив с контролируемым размером = вероятный RCE. READ-only = information disclosure. Null dereference = DoS
- Responsible disclosure - отчёт мейнтейнеру через security@ или GitHub Security Advisory. Стандартный дедлайн: 90 дней
- CVE request - через MITRE CVE form или GitHub CNA
- PoC - после выхода патча, минимальный воспроизводимый пример
Если формула на бумаге понятна, но хочется прогнать crash triage от ASan-отчёта до рабочего PoC руками - на HackerLab.pro в категориях pwn и reverse есть задачи, где нужно проанализировать memory corruption и собрать exploit на готовом стенде.
Девять из десяти русскоязычных материалов по фаззингу - пересказ теории: что такое mutation-based, что такое generation-based, как работает coverage feedback. Для первого знакомства сойдёт, для реальной работы - нет. На практике 90% времени уходит на написание правильного harness и triage крашей, а не на выбор между AFL++ и LibFuzzer. Плохой harness - парсер вызывается с неинициализированным контекстом, глобальное состояние протекает между итерациями, I/O замедляет до 50 exec/sec - и месяц фаззинга даёт ноль. Я видел, как два harness для одной библиотеки давали разницу в coverage 4x за первый час. Второй нашёл use-after-free за 20 минут. Первый не нашёл ничего за сутки. Разница - два часа работы на анализ реальных вызовов в production-коде.
Индустрия сертификации (тот же ГОСТ Р 56939, на который ориентируются российские вендоры) загоняет фаззинг в формальные рамки: 80% покрытия, 1.5 миллиона итераций, два часа стабильности. Формальный подход превращает мощный исследовательский инструмент в checkbox. Реальные 0-day находятся не процентами покрытия, а качеством harness и глубиной triage - и именно этому стоит учиться в первую очередь. На HackerLab есть задачи, где нужно от найденного crash собрать полную цепочку эксплуатации - без подсказок и без EDR в дефолте.
