Burp Suite для начинающих: от перехвата трафика до первой уязвимости

Burp Suite для начинающих: от перехвата трафика до первой уязвимости

На первом в карьере веб-пентесте я потратил два часа на автоматический сканер — он нашёл устаревший jQuery и два отсутствующих security header. Полезного — ноль. Потом открыл Burp Suite, перехватил запрос к /api/user/profile?id=42, заменил 42 на 43 в Repeater — и получил чужие персональные данные. IDOR, Broken Access Control, категория A01:2021 по OWASP Top 10. Сканер это не видел и не увидел бы — тут нужна голова, а не автоматика. Ручная проверка через Burp заняла три минуты. Дальше — пошаговый разбор того, как настроить Burp Suite для начинающих, перехватить первый HTTP-запрос и найти реальную уязвимость через Repeater и Intruder.

Место Burp Suite в цепочке атаки

Burp Suite — HTTP-прокси для пентеста, который встаёт между браузером и целевым сервером. Представьте почтальона, который вскрывает каждое письмо, даёт вам прочитать содержимое, при необходимости — переписать текст, а потом заклеивает конверт и несёт адресату. Вот так и работает перехват и модификация запросов. Подробнее — в нашем статье о пентест веб-приложений.

По классификации MITRE ATT&CK инструмент покрывает несколько тактик:

• Reconnaissance — Active Scanning (T1595) и Vulnerability Scanning (T1595.002): через Proxy и Repeater вы вручную исследуете поверхность атаки, находите скрытые параметры и ошибки валидации
• Credential Access / Collection — Adversary-in-the-Middle (T1557): Burp Proxy технически реализует MITM-позицию между браузером и сервером, перехватывая и модифицируя HTTP-трафик
• Credential Access — Brute Force (T1110) и Password Guessing (T1110.001): Intruder автоматизирует перебор логинов, паролей и токенов
• Initial Access — Exploit Public-Facing Application (T1190): найденные уязвимости (SQL-инъекция, IDOR, XSS) — потенциальные точки входа в систему

В полной цепочке пентеста веб-приложений всё выглядит так: разведка поверхности (Nmap, subfinder) → анализ HTTP-запросов через Burp Proxy → ручное тестирование параметров (Repeater) → автоматизация перебора (Intruder) → эксплуатация найденной уязвимости → пост-эксплуатация. Burp Suite закрывает средний участок — от перехвата трафика до подтверждения уязвимости. Он не заменяет ни разведывательные утилиты на старте, ни фреймворки эксплуатации на финише, но без него ручной поиск уязвимостей веб-приложений — как хирургия вслепую.

Для начинающих пентестеров Burp Suite — стартовый инструмент не потому, что он прост (не прост), а потому, что учит думать о веб-приложениях через призму HTTP-запросов. Когда видишь сырой запрос — заголовки, параметры, cookies — начинаешь понимать, что именно можно менять и к чему это приведёт. Без этого понимания любой сканер — чёрный ящик, который выдаёт результаты непонятно откуда.

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

Перед настройкой Burp Suite проверьте, что рабочее окружение соответствует требованиям:

Параметр	Минимум	Рекомендуется
RAM	4 ГБ	8 ГБ
Процессор	2 ядра	4 ядра
Диск	500 МБ	2 ГБ (проекты и логи)
ОС	Windows 10+, macOS 10.14+, Linux	Kali Linux (Burp предустановлен)
Java	Встроена в инсталлятор	—
Браузер	Firefox или Chrome	Firefox

Burp Suite выпускается в трёх редакциях. Community Edition — бесплатная: включает Proxy, Repeater и Intruder с ограничением скорости. Professional Edition — платная подписка (актуальную цену см. на portswigger.net/burp/pro) — добавляет автоматический сканер уязвимостей и неограниченную скорость Intruder. Enterprise Edition рассчитана на организации с конвейерным сканированием. Для обучения, решения web CTF с Burp Suite и первых шагов в пентесте для начинающих Community Edition хватит за глаза.

Если вы работаете в Kali Linux, Burp Suite Community уже предустановлен — запустите через меню Web Application Analysis или командой burpsuite в терминале. На Windows и macOS скачайте инсталлятор с portswigger.net/burp/communitydownload — Java ставить отдельно не нужно, она включена в пакет.

Настройка Burp Suite: прокси и браузер за 10 минут

Быстрый путь: встроенный браузер

Большинство русскоязычных руководств начинают с ручной настройки прокси в Firefox — и это сбивает новичков на первом же шаге. Между тем в Burp Suite есть встроенный Chromium-браузер, в котором прокси и CA-сертификат уже сконфигурированы. Ноль дополнительной настройки.

Порядок действий:

1. Запустите Burp Suite, выберите Temporary project → Use Burp defaults → Start Burp
2. Перейдите на вкладку Proxy → Intercept
3. Нажмите Open Browser — откроется Chromium с предустановленным проксированием
4. Любой сайт, открытый в этом браузере, автоматически проходит через Burp

Этот вариант идеален для первых экспериментов и решения лаб на PortSwigger Web Security Academy. Минус: встроенный браузер не поддерживает пользовательские расширения (cookie-менеджеры, Tampermonkey), которые пригодятся на сложных тестах.

Настройка Firefox через FoxyProxy

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

1. Установите FoxyProxy из магазина расширений Firefox
2. Кликните на иконку FoxyProxy → Options
3. Нажмите Add → укажите: Proxy IP — 127.0.0.1, Port — 8080, Title — «Burp Suite»
4. Сохраните конфигурацию
5. Кликните на иконку FoxyProxy и выберите созданный профиль

Весь трафик Firefox теперь идёт через Burp. Для выключения — переключите FoxyProxy обратно на «Direct». По руководству Bugcrowd для начинающих, FoxyProxy — стандартная практика в bug bounty workflow: мгновенное переключение между проксированным и обычным режимом без потери рабочего контекста.

Альтернативный путь без расширений: в Firefox откройте Настройки → Основные → Параметры сети → Настроить, выберите Ручная настройка прокси, укажите 127.0.0.1 и порт 8080, отметьте «Использовать этот прокси для всех протоколов». Добавьте localhost, 127.0.0.1 в исключения. Работает, но каждый раз переключать вручную — тоска.

Типичная ошибка новичка: после включения прокси сайты не грузятся. Причина почти всегда одна — Burp Suite не запущен. Браузер шлёт запросы на 127.0.0.1:8080, а там никто не слушает. Запустите Burp или отключите прокси в браузере. Звучит очевидно, но я на это натыкался не раз.

Установка CA-сертификата для HTTPS

Без сертификата Burp Suite браузер покажет предупреждение безопасности на каждом HTTPS-сайте. Если вы используете встроенный браузер Burp — этот шаг не нужен, сертификат уже установлен. Для внешнего Firefox или Chrome:

1. Убедитесь, что Burp запущен и прокси активен в браузере
2. Откройте http://burpsuite (или http://burp) в проксируемом браузере
3. Нажмите CA Certificate — скачается файл сертификата
4. В Firefox: Настройки → Приватность и защита → Просмотр сертификатов → Центры сертификации → Импорт → выберите файл → отметьте «Доверять при идентификации веб-сайтов»
5. В Chrome на Windows: Настройки → Безопасность → Управление сертификатами → импортируйте в «Доверенные корневые центры»

Проверка: откройте любой HTTPS-сайт через прокси. Если предупреждений нет — сертификат установлен корректно. На вкладке Proxy → HTTP history появятся расшифрованные HTTPS-запросы.

Рекомендация из документации PortSwigger: устанавливайте CA-сертификат Burp только в браузер, выделенный для тестирования. Если кто-то получит доступ к вашей инсталляции Burp, он сможет перехватывать ваш HTTPS-трафик через основной браузер. Отдельный профиль Firefox — простая и надёжная изоляция.

Перехват трафика Burp Suite: первый запрос

Перехват и модификация запросов — ядро работы с Burp Suite. Переходим к практике.

1. Откройте вкладку Proxy → Intercept, убедитесь, что переключатель в состоянии Intercept is on
2. В проксируемом браузере перейдите на целевой сайт
3. Страница не загрузится — это нормально. Burp перехватил HTTP-запрос и ждёт вашего решения
4. На вкладке Intercept виден сырой запрос: метод (GET/POST), URI, заголовки (Host, User-Agent, Cookie), тело запроса
5. Forward — отправить запрос серверу. Может потребоваться несколько нажатий, пока страница загрузится полностью
6. Drop — удалить запрос. Сервер его не получит

На практике держать Intercept постоянно включённым неудобно — браузер генерирует десятки запросов на каждую страницу (скрипты, стили, шрифты, трекеры аналитики). Как указано в руководстве PortSwigger (Intercept HTTP traffic with Burp Proxy), оптимальный подход — переключить Intercept в off и работать через HTTP History: все запросы сохраняются и при выключенном перехвате.

HTTP History: разведка целевого приложения

Вкладка Proxy → HTTP history — лента всех запросов, прошедших через прокси. Кликните на любую строку — справа откроются вкладки Request и Response с сырыми данными. Тут и происходит основной анализ HTTP-запросов.

Что искать при разведке:

• Запросы с числовыми параметрами (?id=, ?user=, ?order=) — кандидаты для проверки IDOR
• POST-запросы к /login, /auth, /api/token — точки тестирования аутентификации
• Запросы с JSON-телом — часто содержат скрытые поля, невидимые в интерфейсе
• Ответы с кодом 403 Forbidden — иногда обходятся изменением метода запроса (GET → POST) или заголовков
• Заголовки вроде X-Forwarded-For, X-Original-URL — потенциальные точки обхода контроля доступа

Обязательно настройте Target → Scope, добавив только целевой домен. Это отфильтрует посторонний трафик (CDN, рекламные трекеры, внешняя аналитика) и оставит релевантные запросы. По руководству Bugcrowd для начинающих, настройка scope — один из первых шагов в bug bounty workflow: помимо удобства, scope предотвращает случайное тестирование сторонних сервисов, что может привести к юридическим проблемам. Тут не шутка — можно попасть на статью.

Горячие клавиши для навигации: Ctrl+R — отправить выделенный запрос в Repeater, Ctrl+I — отправить в Intruder. Эти шорткаты экономят заметное время при тестировании множества параметров. Запомните их — руки скажут спасибо.

Burp Suite Repeater: ищем IDOR вручную

Repeater — инструмент для ручного тестирования отдельных запросов. Берёте запрос, меняете один параметр, отправляете, изучаете ответ. Меняете другой — снова отправляете. По сути это диалог с сервером: вы спрашиваете «А если я отправлю вот это?» — и получаете ответ без фильтров. Никакой магии, чистый HTTP.

Пошаговый разбор: поиск IDOR через Repeater

[Применимо: внешний и внутренний пентест, веб-приложения с REST API, web CTF]

Работает если: приложение использует предсказуемые идентификаторы (числовые ID, последовательные UUID) без серверной проверки принадлежности ресурса текущему пользователю. Не работает если: бэкенд привязывает объекты исключительно к сессии и полностью игнорирует параметр ID из запроса.

IDOR (Insecure Direct Object Reference) — подвид Broken Access Control (A01:2021 по OWASP Top 10). По данным OWASP, 94% протестированных приложений имели ту или иную форму нарушения контроля доступа. На практике IDOR — одна из самых частых находок при ручном тестировании через Burp Suite Repeater, и при этом одна из самых простых для понимания.

Сценарий: вы авторизованы как пользователь с id=42 и хотите проверить, доступны ли данные другого пользователя.

1. В HTTP History найдите запрос, содержащий ваш идентификатор — например, GET /api/user/profile?id=42
2. Правый клик → Send to Repeater (или Ctrl+R)
3. Перейдите на вкладку Repeater — запрос отображается слева, ответ появится справа после отправки

GET /api/user/profile?id=42 HTTP/1.1
Host: target-app.local
Cookie: session=abc123def456
Accept: application/json

4. Измените id=42 на id=43 в строке запроса
5. Нажмите Send
6. Изучите ответ

Если сервер вернул данные пользователя 43 (имя, email, телефон) с кодом 200 OK — перед вами подтверждённый IDOR. Если вернул 403 Forbidden или 401 Unauthorized — контроль доступа работает корректно. Поздравляю, тут всё чисто (но не расслабляйтесь).

Не останавливайтесь на одном значении. Повторите проверку с id=1, id=0, id=-1, id=999999. Иногда приложение корректно обрабатывает «соседние» ID, но ломается на граничных значениях или отрицательных числах. Я видел случай, когда id=0 возвращал данные администратора.

Burp Suite Repeater применим для поиска и других классов уязвимостей по OWASP Top 10:

• Injection (A03:2021): добавьте символ ' в параметр — если сервер вернул SQL-ошибку, перед вами потенциальная SQL-инъекция
• Path Traversal: замените значение файлового параметра на ../../etc/passwd и проверьте ответ
• Манипуляция бизнес-логикой: измените поле price или quantity в JSON-теле запроса — если сервер принимает отрицательные значения без валидации, это баг

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

Burp Suite Intruder: автоматизируем перебор

Когда нужно проверить не один параметр, а сотни значений — ручной Repeater не подходит. Intruder автоматизирует отправку запросов, подставляя значения из заранее подготовленного списка (payload). По MITRE ATT&CK это техники Brute Force (T1110) и Password Guessing (T1110.001).

Типы атак и когда какой использовать

Burp Intruder поддерживает четыре типа атак. Без понимания типов легко потратить часы на неэффективный перебор — а в Community Edition с throttling это особенно обидно.

Тип атаки	Payload-позиций	Поведение	Когда применять
Sniper	1+	Один список, позиции тестируются по очереди	Перебор одного параметра: логин ИЛИ пароль
Battering Ram	1+	Один payload вставляется во все позиции одновременно	Одно значение используется в нескольких местах запроса
Pitchfork	2+	Параллельные списки: 1-й payload в 1-ю позицию, 2-й во 2-ю	Проверка пар логин:пароль из слитой базы
Cluster Bomb	2+	Все комбинации: каждый из списка 1 × каждый из списка 2	Полный перебор: все логины × все пароли

Для новичков в 90% случаев достаточно Sniper — он тестирует одну позицию за раз с одним списком payload. Cluster Bomb генерирует число запросов, равное произведению размеров списков: 100 логинов × 100 паролей = 10 000 запросов. В Community Edition с throttling это затянется на часы. Так что Cluster Bomb — штука для Pro-версии или для очень терпеливых.

Практика: перебор логинов на Web Security Academy

Лучший способ попробовать Intruder — бесплатная лаба PortSwigger Web Security Academy. По официальной документации PortSwigger (Getting started with Burp Intruder), порядок действий:

1. Откройте в браузере Burp лабу «Username enumeration via different responses» на portswigger.net/web-security
2. Нажмите Access the lab — развернётся уязвимое веб-приложение с формой логина
3. Попробуйте войти с произвольными логином и паролем — запрос зафиксируется в HTTP History
4. Найдите запрос POST /login, выделите значение параметра username, правый клик → Send to Intruder (Ctrl+I)
5. На вкладке Intruder запрос покажет payload-позицию, обозначенную символами §:

POST /login HTTP/1.1
Host: lab-id.web-security-academy.net

username=§test§&password=wrongpass

6. Тип атаки — Sniper (установлен по умолчанию)
7. На панели Payloads вставьте список имён пользователей (в задании PortSwigger предоставляет готовый список из 101 значения)
8. Нажмите Start attack

Откроется окно результатов. Каждая строка — один запрос с подставленным payload из списка. Payload count и Request count обновятся до 101.

Ключевая колонка для анализа — Length (размер ответа в байтах). Большинство ответов будут одинаковой длины — сервер возвращает одно и то же сообщение об ошибке. Отсортируйте результаты по Length — ответ, который выбивается из общего ряда, заслуживает внимания.

По официальному гайду PortSwigger, в этой лабе все ответы содержат текст «Invalid username» — кроме одного, который возвращает «Incorrect password». Разная формулировка ошибки раскрывает существующий аккаунт — классический username enumeration. Мелочь в тексте ответа, а по сути — утечка информации. Следующий шаг — повторить атаку, зафиксировав найденный username и подставляя список паролей в параметр password.

Что ещё анализировать в результатах Intruder помимо Length:

• Status code: в другой лабе большинство ответов могут возвращать код 401, а один — 302 (redirect), что указывает на сработавший payload
• Response time: аномально долгий ответ на конкретный payload может указывать на time-based инъекцию
• Set-Cookie в заголовках ответа: появление нового cookie после определённого payload — признак успешной аутентификации

Ограничения Burp Suite: когда инструмент не поможет

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

Бизнес-логику автоматически не найдёт. Scanner (только в Pro) ловит технические баги: SQL-инъекции, XSS, отсутствующие заголовки безопасности. Уязвимости в логике приложения — покупка товара за отрицательную цену, обход лимита операций, повторное применение промокода — требуют ручного анализа через Repeater и понимания бизнес-процессов. Никакой автоматикой это не заменить. Тут нужна голова.

Community Edition замедляет Intruder. Throttling в бесплатной версии делает перебор тысяч комбинаций непрактично медленным. Для серьёзного bug bounty или пентеста с брутфорсом — Pro-версия или специализированные утилиты: ffuf для directory fuzzing, Hydra для перебора паролей протоколов, wfuzz для параметрического фаззинга.

Не заменяет специализированные инструменты для веб-пентеста. Для сканирования поддоменов — subfinder, для полноценного directory brute-force — feroxbuster, для автоматической эксплуатации SQL-инъекций — sqlmap. Burp Suite — центр анализа трафика и ручного тестирования, а не швейцарский нож на все случаи жизни.

Генерирует шум. Intruder и Scanner шлют сотни запросов в минуту. На целях с WAF (ModSecurity, Cloudflare) или активным мониторингом это приводит к блокировке IP или алертам в SIEM. Для тихого тестирования лучше работать через Repeater с единичными запросами и паузами.

Ограниченная поддержка нестандартных протоколов. Burp заточен под HTTP/HTTPS. WebSocket-поддержка базовая, а для gRPC, GraphQL Subscriptions или бинарных протоколов нужны расширения из BApp Store или отдельные инструменты. Для поиска первой уязвимости в CTF и типовых веб-приложений это ограничение некритично — учебные задания построены вокруг стандартного HTTP.

Burp Suite — не тот инструмент, с которого принято советовать начинать. Стандартная рекомендация: «сначала Linux, потом сети, потом OWASP Top 10, потом инструменты». Мой опыт говорит обратное: именно этот маршрут приводит к выгоранию. Когда человек три месяца читает теорию без единого практического результата — мотивация исчезает. А когда в первый день перехватываешь HTTP-запрос, видишь cookie в открытом виде, меняешь параметр и получаешь чужие данные — понимаешь, зачем всё это нужно. Теория ложится на практику, а не висит в воздухе.

Я начинал так: сначала Burp и Web Security Academy, потом — осознание пробелов в HTTP, криптографии, SQL. Не по расписанию учебника, а потому что без конкретных знаний не мог решить конкретную задачу. Через полгода лабы PortSwigger перестали казаться загадкой, а первые bug bounty отчёты начали приносить подтверждённые находки. Проблема одна: отдельные лабы дают точечные навыки, но не собирают картину целиком — от сетей до форензики, от криптографии до OSINT. Если хочешь не просто научиться нажимать кнопки в Burp, а получить структурную базу по ИБ — IB Basics на codeby.school укладывает это в пару месяцев, без академического тона и часовых лекций.

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «web».