Caido как альтернатива Burp Suite: настройка, фильтры и первый баг в API

На пентесте API финтех-сервиса Burp Suite сожрал 5 ГБ оперативки при 40 тысячах перехваченных запросов и намертво завис на этапе фильтрации. Caido на том же объёме трафика работал на ~350 МБ без единого сбоя — я замерял. После того проекта я полностью перешёл на Caido для ручного тестирования API и за полгода ни разу не вернулся к Burp для этой задачи. Статья — практический гайд: от установки до первого найденного бага, с готовыми фильтрами для API и честным сравнением двух инструментов.

Почему Caido — реальная альтернатива Burp Suite для ручного тестирования API

Веб-прокси — программа-посредник, которая перехватывает весь HTTP/HTTPS-трафик между браузером и сервером. Это центральный инструмент ручного пентеста. Через прокси проходит каждый запрос, пока вы ищете уязвимости: от манипуляции параметрами до анализа бизнес-логики API.

Если вы только начинаете разбираться в пентесте, полезно знать про MITRE ATT&CK — открытую базу тактик и техник атак, где каждой технике присвоен T-код. Прокси помогает тестировать защищённость от Exploit Public-Facing Application (T1190, тактика Initial Access) и применяется на этапе Vulnerability Scanning (T1595.002, тактика Reconnaissance). По данным Verizon DBIR 2025, веб-атаки составляют 26% всех подтверждённых нарушений. По данным Mandiant M-Trends 2025, эксплойты — самый распространённый вектор первоначального доступа (38%). Ручное тестирование API через прокси — один из основных способов находить такие уязвимости до того, как их найдут злоумышленники.

Burp Suite от PortSwigger — стандарт отрасли последние 15+ лет. Caido — молодой инструмент (публично доступен с 2023 года, активные релизы продолжаются в 2025–2026, инструмент упоминается рядом известных в bug bounty сообществе исследователей). Это не клон Burp с другим интерфейсом — архитектура принципиально другая.

Rust вместо Java: архитектурное отличие

Burp Suite написан на Java и запускает JVM (Java Virtual Machine — виртуальная среда для выполнения Java-кода). Следствие — высокое потребление памяти: даже пустой проект без единого перехваченного запроса занимает около 2 ГБ RAM. На проектах с десятками тысяч запросов потребление уходит за 4–6 ГБ. Это не баг — JVM по умолчанию резервирует значительную часть доступной памяти.

Caido Server написан на Rust — компилируемом языке без сборщика мусора и без JVM. По моим замерам, при запущенном проекте с 10 000+ запросов Caido потреблял в разы меньше памяти, чем Burp с пустым проектом. На практике это значит: можно работать на ноутбуке с 8 ГБ RAM, не закрывая терминал, документацию и мессенджер. Для Burp такой роскоши нет — либо закрываешь всё лишнее, либо свопишь.

Client-server модель и место в цепочке пентеста

Burp Suite — standalone-приложение: запустили на локальной машине, работаете в его окне. Caido устроен иначе: серверная часть (CLI-процесс) обрабатывает трафик, а интерфейс открывается в обычном браузере через HTTP. Практические следствия:

• Развёртывание на VPS: ставите Caido на удалённый сервер, подключаетесь с любого устройства
• Переключение между проектами без перезапуска (в Burp для смены проекта приходится закрывать и открывать заново — на больших проектах это минуты ожидания)
• Работа с нескольких устройств: дневная сессия с ноутбука, вечерняя с десктопа — вся история остаётся на сервере

Коммуникация между интерфейсом и сервером идёт через GraphQL API. Любое действие из UI можно повторить программно — для автоматизации это удобнее Java-плагинов Burp.

В цепочке пентеста Caido занимает этап ручного тестирования: после сбора информации (recon) и автоматизированного сканирования, но до написания отчёта. Это инструмент проверки гипотез: «Этот эндпоинт не проверяет авторизацию? Подменю ID и проверю вручную».

Применимо: внешний пентест (тестирование API через интернет) и внутренний (сервисы внутри корпоративной сети). Для внутреннего сценария client-server модель особенно полезна: Caido на машине внутри периметра, подключение через SSH-туннель.

Настройка Caido для ручного тестирования API

Требования к окружению

• ОС: Windows 10+, macOS 12+, Linux (Ubuntu 20.04+, Kali 2023+)
• RAM: минимум 4 ГБ свободных, рекомендуется 8 ГБ при параллельной работе с браузером и другими инструментами
• Диск: ~200 МБ на установку + место под проекты (зависит от объёма трафика)
• Браузер: Chrome или Firefox с возможностью настройки прокси (или расширение FoxyProxy / SwitchyOmega)
• Сеть: доступ к caido.io для скачивания и активации; после установки инструмент работает offline

Бесплатная версия (Community) ограничена двумя проектами и одним пассивным Workflow, но включает все базовые инструменты: перехват, Replay, HTTPQL-фильтры, Automate. Платная версия — от ~$100/год для индивидуального плана (актуальные цены на caido.io/pricing; для сравнения: Burp Suite Pro стоит $449/год, см. portswigger.net/burp/pro). Есть и командный план.

Установка и подключение браузера

Шаг 1. Скачайте Caido с официального сайта caido.io. На Windows и macOS берите десктопную версию (установщик). На Linux десктоп-версия помечена как экспериментальная — CLI-вариант стабильнее.

Шаг 2. Запустите приложение. При первом запуске создайте аккаунт (нужен для привязки лицензии). После авторизации вы увидите панель проектов — создайте новый, назовите по имени целевого приложения. Если всё прошло правильно, откроется интерфейс с вкладками HTTP History, Replay, Automate.

Шаг 3. Веб-интерфейс Caido по умолчанию открывается на 127.0.0.1:8888, а прокси-listener слушает на 127.0.0.1:8080. Настройте прокси в браузере: в параметрах сети (или через FoxyProxy для Firefox / SwitchyOmega для Chrome) укажите HTTP/HTTPS-прокси 127.0.0.1:8080. Если порт занят — смените в Settings → Proxy.

Шаг 4. Установите CA-сертификат Caido. Без него браузер не будет доверять HTTPS-трафику через прокси — вместо страниц увидите ошибки безопасности. В Caido перейдите Settings → Certificate и скачайте файл. Импортируйте: — Firefox: Settings → Privacy & Security → Certificates → Import → выберите файл — Chrome / Edge: используют системное хранилище ОС — импортируйте через настройки сертификатов Windows/macOS

Ожидаемый результат: откройте любой HTTPS-сайт — его запросы появятся во вкладке HTTP History. Каждая строка — один запрос с методом (GET, POST и т.д.), URL, кодом ответа и размером тела. Если запросов нет, проверьте: (1) прокси в браузере указывает на 127.0.0.1:8080, (2) сертификат установлен и помечен как доверенный.

Быстрый старт без ручной настройки: в верхней панели Caido есть кнопка запуска встроенного браузера (иконка Chrome). Она открывает экземпляр Chrome, уже настроенный на прокси и с установленным сертификатом — удобно для первого знакомства.

Мобильный трафик. Если тестируете API мобильного приложения, на телефоне укажите IP вашей машины и порт 8080 в настройках Wi-Fi прокси, затем импортируйте CA-сертификат Caido в хранилище устройства. На Android 7+ потребуется дополнительная конфигурация доверенных сертификатов (network_security_config) или root-доступ — это отдельная головная боль, но без неё никак.

Фильтры HTTPQL для анализа API-запросов

HTTPQL — собственный язык запросов Caido для фильтрации перехваченного трафика. Если работали с Burp, это аналог строки поиска в HTTP History, но значительно мощнее: ближе к SQL-запросам по выразительности, с автоподсказками прямо в интерфейсе.

Синтаксис HTTPQL и сравнение с Burp

Структура запроса: поле.оператор:"значение". Основные операторы:

• eq — точное совпадение: req.method.eq:"POST"
• cont — содержит подстроку: req.path.cont:"/api/"
• regex — регулярное выражение: req.host.regex:/\.example\.com$/
• ne — не равно: req.ext.ne:"js"
• gte / lte — больше/меньше для числовых полей: resp.code.gte:400

Запросы объединяются через and / or и группируются скобками. При наборе Caido показывает контекстные подсказки — синтаксис осваивается за 10–15 минут без документации.

Для сравнения: чтобы в Burp найти все POST-запросы к /api/, исключая JavaScript-файлы, нужно либо использовать базовый фильтр (где нет regex и сложных условий), либо переключиться в Bambda и писать Java-код с обращением к requestResponse.request(). В Caido это одна строка: req.method.eq:"POST" and req.path.cont:"/api/" and req.ext.ne:"js".

Готовые фильтры для тестирования безопасности API

Ниже — набор HTTPQL-фильтров, которые я применяю на каждом пентесте API. Каждый можно сохранить как preset (кнопка сохранения в строке HTTPQL) и комбинировать с другими.

# Все запросы к API, без статики
req.path.cont:"/api/" and req.ext.ne:"js" and req.ext.ne:"css"

# Мутирующие запросы (POST/PUT/PATCH) — точки инъекции
req.method.ne:"GET" and req.path.cont:"/api/"

# Ответы с ошибками (часто раскрывают внутреннюю структуру)
resp.code.gte:400 and resp.code.lte:599

# Числовые ID в пути — кандидаты на IDOR
req.path.regex:/\/[0-9]+/

# Ответы с email (сигнал утечки данных)
resp.raw.cont:"@" and resp.raw.cont:"email"

Зачем каждый фильтр — коротко:

Первый отсекает статику (JS, CSS, картинки) и оставляет только API-вызовы. На реальном проекте это сокращает шум в десятки раз. Второй выделяет запросы, которые что-то меняют на сервере: создание, обновление, удаление данных. Это основные точки для проверки инъекций (A03:2021 Injection по классификации OWASP — если вы ещё не сталкивались, OWASP Top 10 — каноничный список самых распространённых уязвимостей веб-приложений). Третий ловит ошибки сервера, в которых часто встречаются stack trace, имена таблиц БД, пути к файлам — ценная информация для дальнейшей эксплуатации. Четвёртый находит эндпоинты с числовыми идентификаторами — главные кандидаты на IDOR. Пятый грубый, но на практике эффективный: если API возвращает email-адреса, стоит проверить, не утекают ли данные при подмене ID.

Пресеты комбинируются: создайте «API-only» и «Errors-only», затем применяйте вместе для быстрого поиска проблемных эндпоинтов в большом потоке трафика.

Перехват и модификация запросов: Replay, Automate и Workflows

Если переходите с Burp, вот прямое соответствие вкладок (чтобы не было паники «а где тут мой Repeater»):

Replay — центральный инструмент ручного тестирования API. Берёте запрос из HTTP History, правой кнопкой отправляете в Replay, меняете параметры, нажимаете Send, анализируете ответ. Отличие от Burp Repeater: запросы в Replay организуются в коллекции. Удобно при тестировании нескольких API-эндпоинтов одновременно — коллекция «Auth» с запросами логина, регистрации, сброса пароля; коллекция «Orders» с запросами создания и просмотра заказов. В Burp для этого приходилось нумеровать вкладки вручную и надеяться, что не запутаешься.

Automate (аналог Intruder) — автоматическая подстановка значений. Выбираете позицию в запросе для замены, указываете payload (набор значений: числовой диапазон, список слов, пользовательский файл) и запускаете. В Automate доступны встроенные payload strategies (кодирование, хеширование и др.); для сложных трансформаций используются Convert-блоки в Workflows — можно перебирать числа от 1 до 100, при этом каждое число пропускать через base64-кодирование перед подстановкой.

Workflows — функция Caido, которой в Burp нет. Это визуальные блок-схемы из логических блоков трёх типов: пассивные (срабатывают на каждом перехваченном запросе), активные (запускаются вручную) и Convert (трансформация значений). Полезные сценарии для тестирования API:

• Автоматическая подсветка запросов с admin или internal в пути — сразу видите потенциально привилегированные эндпоинты
• Сохранение всех UUID из ответов в переменные окружения (Environment) для переиспользования в Replay
• Трансформация параметров прямо в запросе: base64-кодирование, MD5-хеширование, URL-encode

Блоки Workflows пишутся на JavaScript, но для простых задач достаточно штатных блоков без кода. Если JS не подходит — есть блок Shell, который выполняет скрипт на любом языке (Go, Python, Bash) через stdin/stdout.

Находим IDOR в API через Caido — пошаговая инструкция

IDOR (Insecure Direct Object Reference) — уязвимость, при которой можно получить доступ к данным другого пользователя, подменив идентификатор в запросе. Звучит просто, но встречается повсеместно. По классификации OWASP это A01:2021 — Broken Access Control (нарушение контроля доступа; по данным OWASP, 94% приложений тестировались на тот или иной вид этой проблемы). В OWASP API Security Top 10 аналогичная уязвимость называется BOLA (Broken Object Level Authorization) — по сути та же проблема, но в контексте API.

IDOR — одна из самых частых находок на пентестах REST API и одна из самых понятных для демонстрации через прокси. Разберём поиск от начала до конца.

Подготовка

• Caido установлен и настроен по инструкции выше
• Целевое приложение с API — для легальной практики подойдут OWASP crAPI (Completely Ridiculous API), DVGA (Damn Vulnerable GraphQL Application), любой CTF-стенд с уязвимым API
• Два аккаунта в целевом приложении (user A и user B) — нужны для подтверждения, что данные одного пользователя доступны другому

Применимо: внешний и внутренний пентест, modern API (REST/GraphQL), grey box (есть учётные данные).

Делай раз, делай два, делай три

Шаг 1. Перехватите трафик целевого приложения.

Залогиньтесь как user A и пройдитесь по функциональности: откройте профиль, список заказов, настройки. Каждое действие генерирует API-запросы, которые появляются в HTTP History.

Ожидаемый результат: в HTTP History — запросы вида GET /api/v1/users/42/profile, GET /api/v1/orders?user_id=42, PUT /api/v1/users/42/settings. Числа (42) — идентификаторы вашего пользователя.

Шаг 2. Отфильтруйте кандидатов на IDOR.

В строке HTTPQL введите: req.path.regex:/\/[0-9]+/ and req.path.cont:"/api/". Фильтр покажет все API-запросы с числовыми идентификаторами в пути — потенциальные точки для подмены.

Ожидаемый результат: список сократится до 5–20 запросов с числовыми ID. Всё остальное (статика, запросы без ID) отфильтровано.

Шаг 3. Отправьте запрос в Replay.

Правой кнопкой по подозрительному запросу → Send to Replay. Откроется вкладка с полным запросом: метод, URL, заголовки (включая Authorization), тело.

Шаг 4. Подмените идентификатор и отправьте.

Измените числовой ID в URL. Если ваш user A имеет ID 42, замените на 43 (или любой другой). Заголовок Authorization оставьте без изменений — вы проверяете, можно ли с токеном одного пользователя получить данные другого. Нажмите Send.

GET /api/v1/users/42/profile HTTP/1.1
Host: target-app.example
Authorization: Bearer eyJ...tokenA...

# Меняем 42 → 43, остальное без изменений
GET /api/v1/users/43/profile HTTP/1.1
Host: target-app.example
Authorization: Bearer eyJ...tokenA...

Два возможных результата:

• Ответ 200 с данными другого пользователя (имя, email, адрес) → IDOR подтверждён. Токен user A дал доступ к профилю user B.
• Ответ 403 Forbidden или 404 Not Found → контроль доступа работает, уязвимости на этом эндпоинте нет. Переходите к следующему кандидату из шага 2.

Шаг 5. Подтвердите находку и оцените масштаб.

Если шаг 4 вернул чужие данные — залогиньтесь как user B и сверьте: совпадает ли полученный через подмену профиль с реальными данными user B. Это исключает ложное срабатывание (бывает, что API возвращает 200 с пустым телом или дефолтными данными).

Для оценки масштаба используйте Automate: выделите числовой ID как позицию подстановки, задайте диапазон (1–100) и запустите. Посмотрите, сколько ответов вернулось с кодом 200 — это покажет, сколько пользователей затронуто.

В отчёте зафиксируйте: затронутый эндпоинт, тип утекающих данных, необходимый уровень привилегий для эксплуатации (любой авторизованный пользователь), классификация A01:2021 Broken Access Control.

Caido vs Burp Suite — trade-off таблица для ручного пентеста API

Почему в сравнении именно эти два инструмента? Burp Suite — стандарт отрасли. OWASP ZAP — бесплатный open-source прокси, но его сильная сторона — автоматическое сканирование и CI/CD-интеграция; для ручного тестирования API интерфейс менее удобен. mitmproxy — мощный консольный инструмент, но без GUI для ручного анализа каждая задача требует Python-скриптинга. Оба заслуживают отдельного разбора, но выходят за рамки этой статьи.

Ограничения Caido и когда Caido-прокси инструмент не подходит

Caido — не универсальная замена Burp Suite. Вот конкретные сценарии, где Caido недостаточен:

Автоматическое сканирование. По данным сравнительного тестирования (afine.com), сканер Caido нашёл ~400 проблем (12 уникальных) против ~1000 у Burp (17 уникальных) на одном целевом приложении. Burp дополнительно предоставляет Audit Log, детальную классификацию находок и рекомендации по устранению. Для автоматизированного аудита Burp Pro остаётся лучшим выбором.

Out-of-band тестирование. OAST (Out-of-band Application Security Testing) — метод обнаружения «слепых» уязвимостей, когда результат эксплуатации виден не в ответе сервера, а через внешний канал: DNS-запрос, HTTP-callback. Burp Collaborator — зрелая инфраструктура с многолетней историей. Плагин Omnioast в Caido — функциональный аналог, но менее зрелый и с меньшим количеством опций.

Экосистема расширений. BApp Store Burp содержит 500+ расширений: от интеграции с Jira до кастомных сканеров под конкретные фреймворки. Магазин плагинов Caido значительно меньше. Перед переходом проверьте, есть ли аналоги критически важных для вас расширений.

Race condition. Burp Pro поддерживает тестирование race condition через single-packet attack — отправку нескольких запросов в одном TCP-пакете для минимизации временного разброса. В Caido эта функция заявлена в roadmap, но на момент написания статьи недоступна. Если вам нужно тестировать race condition — Burp пока безальтернативен.

Документация и обучающие материалы. У Burp — десятки тысяч writeup’ов, PortSwigger Web Security Academy с бесплатными лабами, развитое сообщество на форумах. Материалов по Caido в разы меньше, особенно на русском языке. Для новичка это может быть решающим фактором.

Когда Caido достаточен и предпочтителен: ручное тестирование REST и GraphQL API, bug bounty с фокусом на бизнес-логику и access control, перехват трафика мобильных приложений, любая задача, где основной рабочий инструмент — Replay и фильтры, а не автоматический сканер. Если вы проводите большую часть времени в Repeater, а не в Scanner — Caido может ускорить ваш рабочий процесс.

Полгода с Caido дали одно наблюдение: спор «Caido или Burp» — ложная дихотомия. Caido — инструмент для ручного тестирования, Burp — для автоматизированного аудита и OAST. Две ниши, два инструмента, на ноутбуке открыты оба. На bug bounty платформах уже встречаются writeup’ы с Caido, и их становится больше с каждым кварталом.

Но зацикливаться на выборе прокси — ошибка, которую я наблюдаю у каждого второго новичка. IDOR из этой статьи можно найти в любом инструменте за одинаковое время. Разница не в кнопках интерфейса, а в том, знаете ли вы, что такой класс уязвимостей существует, и умеете ли сформулировать гипотезу до того, как откроете Replay. Инструмент — проводник, не замена знанию. Если хочется не тыкаться вслепую между инструментами, а разобраться в полной картине — IB Basics для тех, кому скучно от Hack The Box без объяснений почему.