10 функций Burp Suite Professional, которые экономят часы на пентесте
Большинство пентестеров используют Burp Suite как продвинутый прокси с Repeater и Intruder. Это нормально, пока не начинаешь считать, сколько времени уходит на рутину: ручной поиск скрытых параметров, ожидание Collaborator-ответов, разбор 30 безымянных вкладок Repeater в конце рабочего дня.
За последние два года PortSwigger добавил несколько функций, которые закрывают конкретные боли. Часть из них вообще не упоминается в официальных release notes с должным акцентом. Ниже: 10 функций, которые стоит знать, если вы используете Professional Edition в реальных проектах.
1. Bambdas: Java-сниппеты прямо в UI
До версии 2023.10 любая нестандартная фильтрация HTTP History требовала написания расширения на Java, его компиляции, установки через Extender. Bambdas убрали этот барьер полностью.
Bambda: Java-лямбда, которую пишешь прямо в интерфейсе. Открываешь HTTP History, жмёшь на иконку фильтра, выбираешь «Bambda» вместо стандартного фильтра — и пишешь однострочник. Та же механика работает в четырёх местах: фильтр в HTTP History, кастомные колонки в таблице запросов, passive scan checks и match-and-replace правила.
Практический пример: тебе нужно видеть только запросы с JWT в заголовке Authorization. Стандартный фильтр это не умеет. Bambda:
return requestResponse.request().hasHeader("Authorization") &&
requestResponse.request().headerValue("Authorization").startsWith("Bearer ey");
Другой сценарий — добавить кастомную колонку «Decoded JWT Payload» прямо в таблицу HTTP History. Вместо того чтобы каждый раз копировать токен в jwt.io, декодированный payload виден сразу. Это реализуется через Bambda для колонок: берёшь заголовок, декодируешь base64-часть, выводишь строку.
Готовые bambdas под распространённые задачи лежат на github.com/PortSwigger/bambdas — фильтр на security headers, поиск IDOR-паттернов, выделение запросов с определёнными параметрами. Проще скопировать и адаптировать, чем писать с нуля.
2. Turbo Intruder для race conditions
Стандартный Intruder отправляет запросы последовательно через встроенный HTTP-стек Java с переиспользованием соединений. Для race condition это бесполезно: нужно отправить 50-100 запросов практически одновременно, в пределах одного-двух миллисекунд.
Turbo Intruder: отдельное расширение с собственным HTTP-движком и Python-конфигурацией. Устанавливается через BApp Store, после этого в контекстном меню Proxy или Repeater появляется «Send to Turbo Intruder».
Конфигурация запускается как Python-скрипт. Для атаки на race condition используешь шаблон из встроенных примеров: `single-packet attack` — все запросы упаковываются в один TCP-пакет, что даёт максимально близкое время доставки на сервер. Это то, что описывал James Kettle в своём исследовании race conditions на DEF CON 31.
Типичный сценарий: промокод без mutex в проверке. Отправляешь 100 запросов на применение одного промокода через single-packet attack — 3-5 из них проходят до того, как сервер успевает проставить флаг «использован». В реальных тестах этот вектор стабильно работает на магазинах с самописной логикой скидок.
Для чего Turbo Intruder ещё используют: проверка race condition в endpoint'ах с лимитами (rate limits на запросы к API, one-time tokens), параллельная проверка IDOR через большой диапазон ID.
3. Param Miner: скрытые параметры
Многие параметры никогда не появляются в UI приложения, но обрабатываются бэкендом: `?debug=true`, `?admin=1`, `?preview=1`, различные заголовки вроде `X-Forwarded-Host` или `X-Original-URL`. Найти их перебором вручную нереально.
Param Miner: расширение от PortSwigger, которое делает именно это. Правый клик на запросе → Extensions → Param Miner → Guess params (или Guess headers, Guess cookies — раздельно). Расширение использует список из ~65 000 имён параметров и отправляет их батчами: несколько параметров за один запрос, анализируя изменения в ответе.
Алгоритм smart batching позволяет обнаружить активный параметр даже если он один из двадцати в батче — через бинарный поиск по изменению ответа. На практике сессия на среднем приложении занимает 10-15 минут и часто даёт неожиданные результаты.
Кроме скрытых функций, Param Miner ищет cache poisoning vectors: параметры и заголовки, значения которых попадают в кэшированный ответ. Это прямой путь к Web Cache Poisoning, если приложение использует CDN или промежуточный кэш.
4. API Scanning через OpenAPI-спецификацию
Когда тестируешь REST API, у которого нет публичного UI, Burp Crawler не помогает — ему нечего обходить. Можно вручную собирать запросы через Repeater, но при 80-100 эндпоинтах это занимает несколько часов только на первичный сбор.
С версии 2024.x Burp Scanner умеет импортировать OpenAPI 3.0 спецификацию (YAML или JSON) и автоматически создавать из неё запросы для сканирования. Путь: Scanner → New scan → API scan → вкладка «API definition» → загружаешь файл или указываешь URL.
Burp автоматически разбирает все пути, методы, типы параметров (path, query, body), схемы запросов и генерирует запросы с корректными типами данных. После этого запускается стандартный аудит: injection в каждый параметр, проверка аутентификации, IDOR между объектами.
На практике это работает именно там, где нужно: внутренние API с документацией, микросервисы с OpenAPI в CI/CD, тестирование по договору когда спецификация есть, а стейджинг — нет. Если спецификация написана аккуратно, покрытие получается близкое к 100% за один прогон.
5. Collaborator: счётчик непрочитанных взаимодействий
Небольшое, но ощутимое улучшение из 2024: на вкладке Collaborator теперь отображается цифра — количество непрочитанных взаимодействий с Collaborator-доменами. Как бейдж уведомлений.
Раньше при длительном тестировании (blind SSRF, blind XXE, DNS rebinding) нужно было периодически переключаться на вкладку Collaborator и вручную проверять таблицу. Если тестируешь параллельно несколько приложений и забыл открыть вкладку — мог пропустить interaction.
Теперь достаточно одного взгляда: цифра на вкладке — есть что смотреть. Без цифры — продолжаешь работать. На первый взгляд мелочь, но за 8-часовой сессию с активным blind-тестированием это несколько десятков ненужных переключений контекста.
6. Match and Replace с Bambda-скриптами
Стандартный Match and Replace в Proxy работает со статическими строками и регулярными выражениями. Это покрывает большинство сценариев — замена User-Agent, добавление заголовков, модификация параметров. Но есть класс задач, где нужна динамическая замена: подпись запроса HMAC, генерация timestamp, ротация токенов по условию.
В версии 2024.9 появился тип правила «Request header (Bambda)» — вместо статической замены пишешь Java-код, который вычисляет значение для каждого запроса. Путь: Proxy → Match and replace → Add → тип «Request header (Bambda)».
Сценарий из реальной практики: API с HMAC-подписью в заголовке `X-Signature: sha256(timestamp + body + secret)`. Раньше нужно было либо писать расширение, либо копировать каждый запрос в отдельный скрипт для подписи. Теперь — Bambda в Match and Replace, который вычисляет подпись на лету для каждого проходящего через прокси запроса. Все инструменты (Repeater, Scanner, Intruder) работают с корректно подписанными запросами автоматически.
7. WebSocket Scanning
Приложения на WebSocket исторически были неудобны для автоматизированного тестирования в Burp: Scanner не умел их обходить, Intruder не поддерживал WS-сообщения в нормальном режиме. Всё тестирование было ручным через WebSockets History.
С 2024 года Scanner включает поддержку WebSocket: при запуске Crawler+Auditor он автоматически обнаруживает и тестирует WS-соединения. Не нужно отдельно настраивать — если приложение открывает WebSocket, Scanner его найдёт и включит в аудит.
Что проверяется: IDOR в сообщениях (подстановка чужих ID), injection в текстовые поля сообщений (XSS, SQLi, SSTI), проблемы аутентификации (отсутствие проверки токена на WS upgrade). Раньше всё это нужно было делать вручную: перехватывать сообщение в WebSockets History, копировать в Repeater, модифицировать, отправлять, смотреть ответ.
На SPA-приложениях, которые активно используют WebSocket для real-time функций (чаты, уведомления, live-обновления данных), это экономит несколько часов на типовом пентесте.
8. Переименование вкладок Repeater
Самая простая функция в списке и при этом одна из наиболее влияющих на рабочий процесс. Двойной клик на заголовке вкладки в Repeater — вводишь имя. Кнопки `<` и `>` рядом с заголовком для навигации между вкладками без мыши.
На типовом пентесте к концу второго дня в Repeater открыто 25-40 вкладок: разные эндпоинты, разные варианты payload, разные пользователи. Без названий: 40 вкладок «Request #1», «Request #2». С названиями: «login-admin», «idor-profile-id», «sqli-search», «race-condition-coupon».
Мелочь с точки зрения разработки функции, но когда возвращаешься к конкретному запросу через три часа после последней с ним работы — разница значительная. Особенно при написании отчёта, когда нужно быстро найти нужный запрос для скриншота.
9. Logger++ с Grep Rules
Стандартный HTTP History в Burp хранит запросы, но возможности фильтрации ограничены. Logger++: расширение из BApp Store, которое сохраняет весь трафик в сортируемую таблицу с расширенной фильтрацией и дополнительными колонками.
Главная здесь — Grep Rules. Это кастомные правила, которые автоматически помечают запросы по условиям в теле ответа или запроса. Примеры реальных правил:
- «Все ответы, где в теле встречается слово `password`» — быстрый поиск утечек credentials в ответах API
- «Все ответы со статусом 500» — список эндпоинтов, которые падают при определённых входных данных
- «Все запросы с заголовком `X-Debug`» — отслеживание специфического заголовка
Пометки видны прямо в таблице. После долгого сканирования или ручного тестирования можно одним фильтром выбрать все потенциально интересные запросы и разобраться с ними разом, не просматривая историю вручную.
Logger++ также удобен для экспорта доказательств: фильтруешь по нужному критерию, выбираешь записи, экспортируешь в CSV. При написании отчёта это быстрее, чем искать нужные запросы в стандартном HTTP History.
10. Nested Insertion Points
По умолчанию Burp Scanner определяет insertion points — места, куда подставляются payload'ы при сканировании — на одном уровне: параметры query string, тело формы, заголовки. Если приложение передаёт данные с несколькими слоями кодирования, Scanner не добирается до внутреннего слоя.
Пример: приложение передаёт JSON в base64 в cookie, а внутри JSON есть поле `userId`. При стандартном сканировании Burp видит cookie как непрозрачную строку и тестирует её как целое. Вложенные injection points внутри не проверяются.
Настройка: Scanner → New scan → Scan configuration → Audit options → «Use nested insertion points». После включения Scanner при обнаружении закодированных данных (base64, URL-encoding, JSON в строке) декодирует их и добавляет insertion points внутрь.
Практические сценарии где это нужно:
- JWT внутри cookie — payload декодируется, каждое поле тестируется отдельно
- JSON в теле form-encoded запроса — `data={"id":1,"action":"read"}` не просто строка, а структура с двумя полями
- Base64-encoded XML в параметре — стандартный вектор для XXE, который без nested insertion points Scanner пропустит
Включение этой настройки заметно увеличивает время сканирования и количество запросов — с этим нужно считаться при ограниченном окне тестирования. Но на приложениях с нестандартным форматом передачи данных разница в покрытии существенная: attack surface, который Scanner обходил стороной, начинает тестироваться.
Где купить Burp Suite Professional
Burp Suite Professional стоит $449 в год на одного пользователя. Подписка включает все обновления в течение года — PortSwigger выпускает их регулярно, несколько раз в квартал, и большинство функций из этого списка появились именно через обновления, а не как отдельные платные модули.
На Prodmag.ru можно оформить покупку с закрывающими документами для бухгалтерии: счёт, акт, закрывающие документы на русском языке. Оплата в рублях по курсу. Лицензионный ключ приходит на почту после подтверждения оплаты.
Если нужна Enterprise Edition или несколько лицензий Professional — пишите на почту или через форму обратной связи, посчитаем точную стоимость под ваш запрос.