Standoff Bug Bounty Tips

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

🧐 Эксплуатация SQL-инъекций при использовании prepared statements

Даже если приложение безопасно обрабатывает SQL-запросы и предпринимаются меры для защиты от SQL-инъекций, использование уязвимой сторонней библиотеки всё равно может свести защиту на нет.

Чаще всего всё ломается на строковых параметрах — если они плохо экранируются, можно сломать синтаксис запроса. Но что если сломать запрос можно не только строками? Например — комментариями.

MySQL требует пробел после --, чтобы строка была интерпретирована как комментарий. А вот PostgreSQL — нет. И тут всё зависит от режима работы:

#️⃣Простой (simple query) — SQL-строка уходит целиком, а параметры клиент подставляет сам.

#️⃣Расширенный (extended query) — SQL и параметры передаются отдельно, что исключает любые синтаксические фокусы.

Но многие клиенты PostgreSQL по умолчанию работают в простом режиме. А иногда расширенный вообще отключён — как, например, в старом PgBouncer или в некоторых конфигах Datadog.

В простом режиме все зависит от того, как библиотека вставит параметры. Например, PgJDBC при запросе SELECT 1-? и значении параметра -1 сгенерирует:

SELECT 1--1

PostgreSQL воспримет -- как комментарий и просто проигнорирует 1. Такая же история — в pg-promise, pgx, pg, pgdriver.

Но можно зайти ещё дальше. Если параметр — многострочная строка, можно внедрить свой код. Комментарий завершится на символе перевода строки, и остальная часть кода будет исполнена. Это даёт возможность внедрить произвольный SQL-код, если вы контролируете параметры.

🔗 Пруфы — в исследовании команды Sonar

🔥 Как превратить blind SSRF в полноценную SSRF: новый подход от команды Assetnote

Blind SSRF в облачных окружениях часто упирается в то, что приложение не возвращает полный ответ — а значит, забываем про доступ к метаданным для получения учетных данных.

💡 Новая техника заключается в циклическом редиректе — и для ее тестирования стоит проверить, как ведет себя приложение в случае нескольких редиректов:

✅ Предположим, несколько редиректов вызывают ошибку парсинга JSON (Exception: Invalid JSON). Если увеличить число до ~30, появляется другая ошибка — NetworkException.

✅ На 500-ой ошибке приложение возвращает полный HTTP-ответ, но нам нужны облачные метаданные, а для них ответ всегда 200, и изменить его нельзя.

✅ Зная, что приложение следует за 3xx редиректами, можно предположить, что некоторые 3xx коды могут вызвать тот же сбой, что и 500. А что если перебрать разные 3xx коды? Пример простого приложения — выше.

При эксплуатации SSRF путем указания URL-адреса, содержащего указанную логику, приложение отвечает полной цепочкой редиректов HTTP и нужным ответом.

🔍 Eval Villain: умный парсинг JavaScript до загрузки страницы

Задумывались, как лучше находить скрытые GET-параметры или отлавливать DOM XSS? Вместо того чтобы тратить время на брутфорс, попробуйте расширение Eval Villain!

⚡️ Что умеет?

💚 Перехватывает нативные JavaScript-функции до загрузки страницы

💚 Парсит URL, сессии и другие параметры.

💚 Рекурсивно декодирует источники и помогает обходить обфускацию

🛠 Как помогает?

💚 Находит скрытые GET-параметры через перехват парсера URL: URLSearchParams.get

💚 Идеально для обнаружения DOM XSS: перехватывает JavaScript sinks и отслеживает ввод на наличие строк, найденных в источниках

💚 Сужает вывод на основе появления URL и артефактов сессии, строк/регулярных выражений, настроенных пользователем, черных списков и других параметров

💨 Повышаем импакт SSTI до RCE

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

Но перед этим важно идентифицировать потенциальную уязвимость SSTI. Один из способов — преднамеренно вызвать ошибку с использованием различных спецсимволов:

{
}
$
#
@
%)
"
'
|
{{
}}
${
<%
<%= 
%>

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

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

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

▪️Python: Jinja2, Mako
▪️PHP: Twig, Smarty
▪️JavaScript: EJS, Handlebars, Pug
▪️Java: Thymeleaf, FreeMarker, Pebble
▪️C#: Razor
▪️Ruby: ERB, HAML, Slim

🔥 Реверс JavaScript еще никогда не был таким простым

В DevTools есть функция debug(), которая ставит breakpoint каждый раз, когда вызывается переданный в нее аргумент.

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

debug(DOMParser.prototype.parseFromString)

💡 4 простых способа обхода ошибки 403 (Forbidden) и получения доступа к админке

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

💬 Какие способы вам удавалось применять на практике? Делитесь в комментариях 👇

🔍 Как найти баги в API: 12 проверенных способов

Это далеко не все возможные техники, но именно они чаще всего приводят к результату на практике:

1️⃣ Blind XSS через заголовки: приложения могут логировать ваши данные различными способами, поэтому проверяйте XSS-пэйлоад в HTTP-заголовках (X-Forwarded-For, Referrer, User-Agent и других)

2️⃣ Устаревшие API: /api/v2 → /api/v1, /api/v2 → /api/, api-v2.example.com → api-v1.example.com или api.example.com

3️⃣ SSRF: заменяйте любой URI в запросах на контролируемый вами ресурс через Proxy Interceptor Match & Replace Rule и ждите входящие соединения

4️⃣ Поиск эндпоинтов: используйте GitHub, Google/Yandex дорки, анализируйте JavaScript, Swagger API или другую документацию

5️⃣ CSRF: удалите или замените anti-CSRF токен, меняйте Content-Type и метод запроса

6️⃣ Эксплуатация JWT: ищите слабые алгоритмы подписи, пробуйте манипулировать с токенами

7️⃣ Обход 401/403: попробуйте получить доступ ко вложенному пути (/admin 401 → /admin/system-resources 200), добавьте спецсимволы или измените методы запроса

8️⃣ Неправильная настройка CORS: проверьте правильность настроек CORS и убедитесь, что API позволяет отправлять запросы из любого источника с использованием учётных данных

9️⃣ Тестирование race conditions: проверяйте так называемые high-value транзакции — загрузка файлов, размещение заказов, платежи, переводы

1️⃣0️⃣ XXE: измените Content-Type с application/json на application/xml и проверьте на наличие XXE

1️⃣1️⃣ NoSQL инъекция: манипулируйте параметрами и добавляйте MongoDB (или любой другой NoSQL БД) пэйлоад для обхода ограничений

1️⃣2️⃣ Обход загрузки файлов: пробуйте загрузить файлы с нестандартными расширениями или без них, используйте известные методы обхода (null byte, magic byte и другие)

Что отличает опытного багхантера от новичка? Возможность наткнуться на что-то с низким импактом и раскрутить до более серьезной проблемы💡

Web cache deception — в помощь!

⤴️ Arbitrary file write —> Remote code execution

В реальной практике существует несколько кейсов, с которыми можно столкнуться при повышении от AFW к RCE в веб-приложениях. Их можно обобщенно разделить на следующие категории:

🔘Контроль полного пути файла или только имени загружаемого файла, но не его содержимого.

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

🔘Контроль только над содержимым загружаемого файла, но не над его путем. В этом случае последствия могут сильно различаться из-за множества факторов.

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

Тактики для достижения RCE через AFW:

1️⃣ Перезапись или добавление файлов, обрабатываемых сервером:

— Конфигурационные файлы (.htaccess, .config, web.config, httpd.conf)
— Исходники, доступные для выполнения (.php, .jsp)
— Временные/сессионные файлы, файлы с секретами

2️⃣ Манипуляции с procfs для выполнения произвольного кода

3️⃣ Перезапись системных файлов:

— Cron, bash-скрипты (.bashrc, .bash_profile)
— Файлы authorized_keys и authorized_keys2 для получения доступа через SSH

👉 Еще один интересный кейс

Предположим, что уязвимость позволяет загружать и изменять файлы через функцию экспорта в PDF.

Приложение работает на uWSGI, который поддерживает различные способы конфигурации, включая загрузку конфигов через обычные .ini файлы.

uWSGI поддерживает «магические» переменные (@exec://), которые позволяют выполнять произвольные команды.

При включенной опции py-auto-reload перезагрузка конфигурации может быть вызвана изменением Python-файлов, что дает шанс выполнить команду.

💪 Собираем в цепочку

1️⃣ Генерируем и проверяем PDF-файл:

 
uwsgi --ini payload.pdf

2️⃣ Загружаем payload.pdf в /app/console/uwsgi-sockets.ini

3️⃣ Ждем перезапуск сервера или принудительно перезагружаем uWSGI, перезаписав все .py файлы

4️⃣ Проверяем коллбэк и сдаем багу

🧠 Инфраструктура вокруг модели — вот где живут баги

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

💜ИИ-функциональность нередко использует iframe или компоненты с динамическим рендерингом

Это снова открывает возможности для классических атак на клиенте, таких как XSS и небезопасная работа с postMessage. Всегда проверяйте интеграцию LLM на фронте.

💜Кастомные API, которые подключаются к моделям, требуют тщательного тестирования

Обратите внимание на IDOR или другие ошибки контроля доступа — особенно в том, как API обрабатывает данные ещё до того, как они попадут в модель.

👉 Помимо этого, существуют и специфические уязвимости, характерные для ИИ-систем:

— В системах RAG (Retrieval Augmented Generation) может произойти утечка внутренних данных
— В архитектурах с циклической логикой возможны злоупотребления через tool chaining
— Даже LLM, работающие в CLI, могут быть уязвимы к атакам с использованием ANSI escape-последовательностей

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

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

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

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

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

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

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

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

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

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

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

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

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