🔍 Обнаружение уязвимостей 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, секреты или большие ответы.

🔥 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 всё ещё отрабатывает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Современные веб-архитектуры любят кэширование. Их много: на уровне приложения, на уровне 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

💉 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-- -