Хотите попрактиковаться в навыке подбора джейлбрейков для взлома AI? С 5 мая до 1 июля проводится соревнование для подбора промпт-атак Hackaprompt 2.0. 30 мая открывается трек по тестированию агентных систем на стойкость к атакам.

Кто взломает больше агентов? 🚀

🕷 Как найти и проэксплуатировать Blind XSS

Blind XSS отличается тем, что вредоносный скрипт выполняется в компонентах, недоступных атакующему — например, во внутренней админке или панели поддержки, доступной только админу/сотрудникам.

Зачастую для срабатывания пэйлоада нужен пользователь с «другими» привилегиями. И да, обычный alert() тут не поможет. Примеры пэйлоада ☝️

🧰 Инструменты для поиска и эксплуатации blind XSS

Чтобы поймать «отстук» от внедренного пэйлоада, потребуется внешний контролируемый эндпоинт, который будет слушать и обрабатывать обратные вызовы.

Использовать готовые инструменты (Burp Collaborator, requestbin) или развернуть на своем сервере (ezXSS, XSSHunter) — дело ваше. Последний можно поднять за пару минут:

$ docker-compose up -d postgresdb
$ docker-compose up xsshunterexpress

🔍 Где искать blind XSS?

▪️Формы обратной связи (особенно когда компания не полагается на сторонних вендоров для этой функции)

▪️Аналитические системы (UTM параметры, referrer, заголовки запроса)

▪️Блоги и справочная документация (логирование поисковых запросов)

▪️Сообщения об ошибках и исключениях (URL, заголовки, cookies)

▪️Счета и накладные (поля адреса, имя плательщика)

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

💡 Попробуйте намеренно вызвать исключение или ошибку и внедрить пэйлоад в любое возможное поле, которое может быть проанализировано и обработано позже (URL, User-Agent, файлы cookie, username/email, заголовок X-Forwarded-For и другие).

👉 Погрузиться подробнее:

🔗 Статья «Слепая простота» от Луки Сафонова
🔗 Гайд от Intigriti + настройка XSSHunter

#советы #инструменты

🕷 Запутались в десятках вкладок Burp Repeater во время поиска багов?

Сгруппируйте их по смыслу и вернитесь позже — с чистой головой и новыми идеями 💡

#советы #инструменты

🤔 Чтобы находить криты, важно мыслить как бизнес

1️⃣ Каждое приложение имеет свой «сундук с сокровищами». У телекомов — номера телефонов. У SaaS — данные тенанта.

Понимая, что для компании критично, вы можете бить туда, где больно.

2️⃣ Баги часто рождаются не в фичах, а в пересечениях. Например: «инвайт пользователя» + «автоназначение роли админа» = повышение привилегий.

Смотрите на флоу в связке, а не поодиночке.

3️⃣ Задавайте себе вопросы как атакующий:

— А если отложить вызов?
— А если пропустить шаг?
— А если скомбинировать два эндпоинта?

Создавайте истории атак, а не просто чек-лист с OWASP.

4️⃣ Перед тем как тыкать кавычки — спланируйте атаку:

— Обход аутентификации?
— Повторное использование токена?
— Путаница сессий?
— ...

5️⃣ Тыкать наобум ≠ тестировать, поэтому верифицируйте свои гипотезы последовательно.

Контекст + упорство дают результат.

#советы

🕷 Фаззинг в багбаунти: как с Burp Suite, только через CLI

Многие используют популярный инструмент ffuf для веб-фаззинга, но знаете ли вы о его ограничениях? Он использует Go-библиотеки net/http и net/url, которые не позволяют добиться фаззинга сырых запросов.

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

💡 Решение — использовать форк ffuf под названием uff, который приносит в CLI всю мощь фаззинга и поддерживает:

#️⃣Основные флаги и возможности ffuf

#️⃣Фаззинг сырых запросов и абсолютного URI: как в Burp Suite или Caido

#️⃣Точные HTTP-заголовки: никаких изменений, можно даже с пробелами или без двоеточия — идеально для cache poisoning и request smuggling

#️⃣-request: отправка запросов из файла, без изменения порядка заголовков, пропущенных некорректных битов и т. д.

#️⃣-no-content-length: полный контроль над телом запроса, что помогает ловить странное поведение серверов

➡️Простой пример:

echo hi | uff -c -u http://example.com -w - -opaque "http://127.0.0.1/FUZZ"

👇

GET http://127.0.0.1/hi HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip

P. S. Uff дает больше гибкости и точности в фаззинге, устраняя ограничения оригинального ffuf и адаптируясь к современным задачам. Он отлично подойдет для тестирования API, поиска скрытых эндпоинтов/параметров, экспериментов с нестандартными HTTP-запросами.

#техники #инструменты

🕷 PDF может быть… валидным JavaScript?

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

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

👉 Погрузиться в тему подробнее

#техники #советы

🥠 Cookie Tossing: когда поддомен подбрасывает «левую» cookie

Cookie Tossing — малоизвестная, но серьёзная атака. Атакующий, контролирующий поддомен (например evil.example.com), устанавливает в браузере атакуемого cookie так, чтобы она применялась ко всему родительскому домену .example.com.

Когда атакуемый открывает account.example.com или любой другой поддомен, браузер автоматически отправляет поддельную cookie, и сервер может обработать именно её. Так можно, например, привязать OAuth-токен к учётной записи атакующего, сбросить настройки или подменить сессию.

📌Как это работает

Атака опирается на два параметра cookie:

* Domain определяет, на какие хосты отправляется cookie. Если указать Domain=example.com, она уйдёт на все поддомены.

* Path задаёт, к каким URL-ам применяется cookie. Более узкий путь (/settings/account) даёт ей приоритет над cookie с общим путём (/).

📌Как браузер выбирает cookie

Если в браузере есть две cookie с одинаковым именем, он включает обе в заголовок Cookie, а порядок определяется так:

1. Сначала идут cookie, чей Path точнее совпадает с путём запроса.

2. При одинаковом пути первой идёт более старая cookie.

Пример:

# cookie в браузере
session_cookie=<attacker>; Domain=example.com; Path=/settings/account
session_cookie=<victim>;   Domain=example.com; Path=/

# запрос к /settings/account
Cookie: session_cookie=<attacker>; session_cookie=<victim>

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

📌Когда проверять на Cookie tossing

* У сайта есть поддомены, и на них можно внедрить пользовательский JS/HTML.

* Сессионная cookie выдаётся на весь домен (Domain=.example.com).

* Важные эндпоинты (/auth/callback, /settings/account, /billing) не защищены CSRF-токеном.

* Аутентификация основана только на cookie, без дополнительного заголовка или токена.

📌Как протестировать

1. Найдите XSS на поддомене.
2. Установите cookie с нужным Domain и «узким» Path:

document.cookie = "session_cookie=attacker_val; Domain=example.com; Path=/settings/account";

3. Если атакуемый переходит на account.example.com/settings/account и приложение выполняет действие в контексте атакующего либо подменяет сессию — уязвимость подтверждена.

Удачной охоты!

#техники #clientside

🧠 Kiterunner — API enumeration для тех, кто устал от 404

🎣 Знаете, что общего у классического ffuf и рыбалки без наживки? Ты вроде что-то делаешь, но ни черта не ловится, особенно если в приложении используется REST API.

Эту проблему решает инструмент Kiterunner от Assetnote, который не просто брутфорсит пути, а делает это с контекстом:

➡️Знает правильные HTTP-методы
➡️Знает, что /user/create работает только с POST
➡️Сам подставляет UUID, id-шники и даже нужные заголовки

💡Как он это делает?

Команда собрала ~67,500 Swagger файлов со всего интернета (даже с BigQuery и APIs.guru) и сделала на их основе датасеты роутов, которые можно использовать для сканирования.

📌 Пример

GET /download —> 404
GET /download/123456 —> 200 (файл!)

Или:

GET  /user/create —> 404
POST /user/create —> 500 (значит, эндпоинт жив)

📂 Вишенка на торте — можно реплеить запросы в Burp, чтобы изучить поведение вручную:

kr replay -w routes.kite --proxy http://localhost:8080 "POST ..."

#инструменты #api

💡 Фича-флаги для багхантера

Обращайте внимание на всё, что в HTML содержит featureFlag или просто flag. Часто разработчики проводят A/B-тесты, и фичи «выключены» у вас на глазах.

Иногда достаточно:

▪️поменять false на true,
▪️или добавить строку в массив через match-and-replace в Burp.

⚙️ Больше включённых фич → больше функциональности → шире зона охвата → больше уязвимостей. Проверяйте скрытые возможности — они любят ломаться первыми.

😈 Использование больших файлов в Burp Intruder

Просто напоминаем: если ты хочешь работать с большим файлом в Burp Intruder (условный rockyou.txt), НЕ ИСПОЛЬЗУЙ Load ... в Simple list. Simple list предназначен для простых словарей и загружает весь файл в GUI.

Большой файл повесит Burp, что может привести к потере данных проекта. Вместо этого используй Runtime file!

P. S. Скорее всего, увеличение оперативки не поможет 🤷‍♂️