От обхода фильтрации email-адресов до SQLi 😓
Если система фильтрует email-адреса и запрещает спецсимволы, попробуй обойти проверку через кавычки перед🤕
Дальше начинается самое интересное — внутри кавычек можно размещать пэйлоад:
Твоя задача — аккуратно сломать валидатор, который определяет корректность адреса по RFC и пропустить вредоносный ввод в бэкенд. Если разработчики привязали фильтрацию email к SQL-запросу без параметров — дорога к SQLi открыта💨
Если система фильтрует email-адреса и запрещает спецсимволы, попробуй обойти проверку через кавычки перед
@. Формат "username"@domain.com валиден по RFC 3696, и большинство валидаторов об этом «забывают» Дальше начинается самое интересное — внутри кавычек можно размещать пэйлоад:
“<noscript src=//xsshere?”@email.com
“1-’or’1'=’1”@email.com
...
Твоя задача — аккуратно сломать валидатор, который определяет корректность адреса по RFC и пропустить вредоносный ввод в бэкенд. Если разработчики привязали фильтрацию email к SQL-запросу без параметров — дорога к SQLi открыта
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16
От простой IDOR до критической утечки PII 😓
Когда доступ к файлам «защищён» сложными идентификаторами, это почти всегда означает одно: уязвимость не исправили, а спрятали под ковёр. Кейс из райтапа хорошо показывает, как такие баги выходят наружу⤵️
Если ты нашёл классическую IDOR — с одного аккаунта можешь получить доступ к файлам другого —
но
→ IDOR есть, но как получить другие идентификаторы?
1️⃣ Найди эндпоинты, куда клиент передаёт имя файла:
Подходящие параметры:
*
*
*
* blob_name
Такие точки входа обычно встречаются в загрузке, обновлении статуса и регистрации документов.
2️⃣ Попробуй отправить пустой ключ
Частая ошибка бекенда — передавать значение в storage/SDK как есть.
S3-совместимые хранилища интерпретируют пустой ключ как
3️⃣ Если получил список — используй пагинацию
S3 и аналоги отдают:
* первые 1000 файлов
* флаг
* последний ключ, который можно использовать как
Так можно пройти весь бакет и собрать имена файлов💭
4️⃣ Подставь полученный ключ в «легитимный» эндпоинт
Если есть эндпоинт, который:
* принимает
* возвращает
— подставь туда любой найденный ключ.
Если сервер не проверяет владельца файла, он подпишет URL к чужому объекту. Это и есть полноценный IDOR💡
Когда доступ к файлам «защищён» сложными идентификаторами, это почти всегда означает одно: уязвимость не исправили, а спрятали под ковёр. Кейс из райтапа хорошо показывает, как такие баги выходят наружу
Если ты нашёл классическую IDOR — с одного аккаунта можешь получить доступ к файлам другого —
GET /api/v1/files/view/{file_id} HTTP/2
Host: api.example.com
Authorization: Bearer <ACCOUNT_B_JWT>но
file_id имеет сложный формат:[UserID]_[Filename]_[Timestamp]_[UniqueID]
→ IDOR есть, но как получить другие идентификаторы?
Подходящие параметры:
*
document_key*
file_key*
object_key* blob_name
Такие точки входа обычно встречаются в загрузке, обновлении статуса и регистрации документов.
Частая ошибка бекенда — передавать значение в storage/SDK как есть.
document_key: ""
document_key: " "
document_key: "%20"
document_key: null
S3-совместимые хранилища интерпретируют пустой ключ как
ListBucket и возвращают список файлов.S3 и аналоги отдают:
* первые 1000 файлов
* флаг
IsTruncated: true* последний ключ, который можно использовать как
?marker=...Так можно пройти весь бакет и собрать имена файлов
Если есть эндпоинт, который:
* принимает
document_key* возвращает
pre-signed URL или прямой доступ— подставь туда любой найденный ключ.
Если сервер не проверяет владельца файла, он подпишет URL к чужому объекту. Это и есть полноценный IDOR
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤2🤔2🤨2
Max-Forwards HTTP header ⏳
Во многих приложениях запросы проходят через цепочку прокси, балансировщиков и кэшей. Это скрытый слой инфраструктуры, который часто остаётся «невидимым» — а зря.
Один из способов подсветить эту цепочку — заголовок
По стандарту он применяется к методам
💙 По разным ответам при разных значениях
💙 Иногда запросы начинают вести себя по-разному → можно увидеть несогласованную конфигурацию, нестабильные фильтры, проблемные балансировщики
💙 Это помогает находить расхождения в маршрутизации и потенциальные точки обхода
Кейс редкий, но в правильный момент — очень показательный. Попробуй отправить💡
Во многих приложениях запросы проходят через цепочку прокси, балансировщиков и кэшей. Это скрытый слой инфраструктуры, который часто остаётся «невидимым» — а зря.
Один из способов подсветить эту цепочку — заголовок
Max-Forwards. Если отправить запрос с этим заголовком, можно ограничить количество промежуточных узлов, которые обработают запрос. По стандарту он применяется к методам
TRACE и OPTIONS, но в реальных системах встречается куда шире. Вот почему это полезно:Max-Forwards можно понять, сколько прокси стоит перед приложениемКейс редкий, но в правильный момент — очень показательный. Попробуй отправить
TRACE / или OPTIONS / с разными значениями Max-Forwards и сравни ответы — иногда цепочка раскрывается сама Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7🤔3🫡1
Упрощаем обработку приложений APK / XAPK / APKM / DEX / JAR / WAR с помощью BFScan ⚡️
Когда разбираешь мобильное приложение, главная боль — собрать карту API. Proxy ловит не всё, OpenAPI нет, код обфусцирован, запросы раскиданы по 20 классам.
📦 BFScan решает эту проблему. Это статический анализатор, который вытаскивает HTTP-запросы, эндпоинты, параметры и даже черновую OpenAPI-спеку прямо из APK / XAPK / APKM / DEX / JAR / WAR.
🎯 Что вытаскивает
⚫️ URL, пути, токены, API-ключи и другие подозрительные строки
⚫️ Сырые HTTP-запросы
⚫️ OpenAPI-спецификацию (по аннотациям и конфигам)
⚫️ Захардкоженные секреты
🔍 Что анализирует
Клиентские библиотеки:
⚫️ Retrofit
⚫️ Ktorfit
⚫️ Feign
Серверные фреймворки и аннотации:
⚫️ Spring Web
⚫️ JAX-RS / Jakarta REST
⚫️ Jakarta Servlets
⚫️ Micronaut
⚫️ Struts 1/2
⚫️ Ktor routing
⚫️ Play Framework
⚫️ Swagger / OpenAPI-аннотации
⚫️ web.xml / jetty.xml
🧵 Что удобно для реверса
⚫️ Автоматически декомпилирует даже обфусцированный код через
⚫️ Сшивает роуты, методы, параметры и тела запросов
⚫️ Даёт готовую базу для тестирования API, даже если приложение — чёрный ящик
🧪 Зачем багхантеру
⚫️ Быстрое перечисление скрытых методов API
⚫️ Поиск забытых эндпоинтов, внутренних роутов, legacy-методов
⚫️ Детект захардкоженных секретов → токены бэкенда, тестовые креды, Firebase-ключи
⚫️ Расширение поверхности атаки для мобилок и веба
⚫️ Отличная база для SSRF, IDOR, авторизационных багов, parameter pollution
Когда разбираешь мобильное приложение, главная боль — собрать карту API. Proxy ловит не всё, OpenAPI нет, код обфусцирован, запросы раскиданы по 20 классам.
📦 BFScan решает эту проблему. Это статический анализатор, который вытаскивает HTTP-запросы, эндпоинты, параметры и даже черновую OpenAPI-спеку прямо из APK / XAPK / APKM / DEX / JAR / WAR.
🎯 Что вытаскивает
🔍 Что анализирует
Клиентские библиотеки:
Серверные фреймворки и аннотации:
🧵 Что удобно для реверса
jadx🧪 Зачем багхантеру
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍3
Выполняем JS-код внутри <noscript><noscript> 💨
Внутри тега
Это приводит к интересному эффекту. Если написать что-то вроде:
то последовательность внутри не считается JS-комментарием, и не считается HTML-элементом, а попадает под категорию «некорректный HTML-тег»💲
HTML-парсер пытается «исправить» такую конструкцию — он удаляет невалидный HTML,
оставляя от исходного текста только:
Внутри тега
<noscript><noscript> браузер обрабатывает содержимое не как HTML, а как JavaScript-код. При этом действует важное правило парсера:Внутри <noscript> только текстовые узлы становятся JavaScript-кодом.
Комментарии или вложенные SVG/HTML-элементы удаляются парсером.
Это приводит к интересному эффекту. Если написать что-то вроде:
<noscript><noscript>al<//looks like js comment>ert(document.domain)</noscript>
или
<noscript><noscript>al</h1>ert(document.domain)</noscript>
то последовательность внутри не считается JS-комментарием, и не считается HTML-элементом, а попадает под категорию «некорректный HTML-тег»
HTML-парсер пытается «исправить» такую конструкцию — он удаляет невалидный HTML,
оставляя от исходного текста только:
al + ert(document.domain) → alert(document.domain)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Если в ходе рекона ты нашел файл ⤵️
В быстрой проверке поможет NPM Dependency Confusion Validator — новый инструмент от JSMon🔥
package.json, возможно, некоторые внутренние пакеты уязвимы для атаки, связанной с dependency confusion В быстрой проверке поможет NPM Dependency Confusion Validator — новый инструмент от JSMon
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤4
Необычное поведение href: как ограниченный DOM Clobbering превратить в полноценный Client-Side Path Traversal 🌫
Если в🚨
🟡 В обычном случае приложение и фильтры (например, DOMPurify) блокируют все протоколы, кроме
🟡 Но при использовании формы
🟡 Это делает возможным обращение к эндпоинтам или выполнение действий, которые при нормальном парсинге URL были бы невозможны.
Идём дальше: почти любые символы после🏃
Если в
href указать невалидный протокол вроде ftp:: или https::, браузер перестаёт интерпретировать атрибут как URL. Это полностью ломает ожидаемую логику проверки протоколов и открывает дополнительные векторы атак http и https.https:: строка уже не считается URL, и проверки протокола не срабатывают.Идём дальше: почти любые символы после
: приводят к аналогичному результату — браузер прекращает парсинг как URL и оставляет значение как обычный текст Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Unicode-суррогаты: как один битый символ превращается в обход валидации 🔡
В некоторых системах одиночные Unicode-суррогаты работают необычно: валидатор пропускает их как обычные буквы, а внутренние сервисы преобразуют их в вопросительный знак.
В ряде баз данных💭
Багхантер Krzysztof Balas нашел публичный эндпоинт, который отдавал данные пользователя, если ввести:
⚫️ дату рождения,
⚫️ фамилию,
⚫️ ZIP-код.
Авторизация не требовалась. После первого репорта разрабы закрыли все спецсимволы, URL-encoding и даже «юникодные аналоги» запрещённых символов.
Но осталось кое-что ещё — одиночные Unicode-суррогаты, например
, то парсеры UTF-8 не смогут корректно отобразить Unicode-суррогаты, которые часто используются в эмодзи с low и high парами. Все, что ты получаешь при попытке их отобразить, — это символ замены Юникода.
Некоторые парсеры, по-видимому, идут еще дальше и упрощают символ замены до вопросительного знака (💡
В некоторых системах одиночные Unicode-суррогаты работают необычно: валидатор пропускает их как обычные буквы, а внутренние сервисы преобразуют их в вопросительный знак.
В ряде баз данных
? — это wildcard. Так и возникает уязвимость, которая даёт доступ к данным Юникод использует диапазон символов U+0000–U+10FFFF. Но старый формат UTF-16 не мог напрямую закодировать все символы выше U+FFFF, поэтому придумали специальный механизм — суррогаты. Есть два типа:
High surrogates — старшие суррогаты
Диапазон: U+D800–U+DBFF
Low surrogates — младшие суррогаты
Диапазон: U+DC00–U+DFFF
По отдельности они не являются валидными символами. Но если записать их пару (high + low), то вместе они кодируют один символ за пределами базовой области Unicode (например эмодзи).
Пример: эмодзи 😄 — это комбинация двух суррогатов в UTF-16.
Багхантер Krzysztof Balas нашел публичный эндпоинт, который отдавал данные пользователя, если ввести:
Авторизация не требовалась. После первого репорта разрабы закрыли все спецсимволы, URL-encoding и даже «юникодные аналоги» запрещённых символов.
Но осталось кое-что ещё — одиночные Unicode-суррогаты, например
\udc2a. Если отправить что-то вроде:"lastname": "D\udc2a\udc2a",
"zipcode": "1\udc2a\udc2a\udc2a\udc2a"
, то парсеры UTF-8 не смогут корректно отобразить Unicode-суррогаты, которые часто используются в эмодзи с low и high парами. Все, что ты получаешь при попытке их отобразить, — это символ замены Юникода.
Некоторые парсеры, по-видимому, идут еще дальше и упрощают символ замены до вопросительного знака (
?), что и приводит к возникновению уязвимости Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2🤯2
Как слияние HTML-атрибутов превращается в рабочий XSS-вектор ⚡️
У страницы может быть только один🎨
Поскольку некоторые санитайзеры могут не учитывать механизм объединения атрибутов, можно использовать эту фичу для разделения XSS-вектора по нескольким тегам:
После парсинга браузер сформирует единый
1⃣
2⃣ Когда анимация завершается, событие
3⃣ Санитайзер может пропустить такой пэйлоад, так как опасные атрибуты находятся в разных местах и выглядят безвредно по отдельности.
➡️ При написании поста вдохновились этим исследованием
У страницы может быть только один
<html> и один <body>. Если определить большее количество, их атрибуты будут объединены с атрибутами первого элемента Поскольку некоторые санитайзеры могут не учитывать механизм объединения атрибутов, можно использовать эту фичу для разделения XSS-вектора по нескольким тегам:
<body style=animation:x id='First Body Tag'>
<body onanimationend=alert(this.id)>
<style>@keyframes x{
После парсинга браузер сформирует единый
<body>, в результате чего:style=animation:x активирует фиктивную CSS-анимацию.onanimationend вызывает JavaScript.Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11
Малоизвестные техники для масштабного перечисления поддоменов 🔥
Активная DNS-разведка обычно сводится к следующему набору:
❌ хороший словарь (Assetnote, SecLists и т.д.),
❌ список «проверенных» публичных рекурсивных DNS-серверов,
❌ инструмент для массовых DNS-запросов: massdns, puredns, shuffledns.
Публичные DNS-серверы слушают UDP/53 и принимают запросы со всего интернета. Многие из них перегружены, неправильно настроены, либо намеренно возвращают ложные ответы.
Результат — шум,
Что лучше?
Запросы напрямую к авторитативному DNS-серверу почти всегда лучше, чем использование публичных рекурсивных резолверов.
Техники для глубокой разведки💃
1️⃣ ENTs и NOERROR
В DNS есть промежуточное состояние, которое большинство инструментов игнорирует: Empty Non-Terminals. Они возвращают
Отлично подходят для поиска скрытых поддеревьев и позволяют избежать бесполезного фаззинга.
2️⃣ NSEC / NSEC3 zone walking
NSEC формирует связанный список валидных имён, поэтому обход зоны тривиален с инструментами вроде ldns-walk. NSEC3 хеширует имена, но всё ещё позволяет:
▪️ собирать хешированные метки,
▪️ офлайн брутфорсить их с помощью инструментов вроде nsec3map,
▪️ восстанавливать структуру зоны.
3️⃣ ICANN CZDS
CZDS предоставляет полные файлы зон для множества gTLD. Если твой таргет использует редкий TLD, часто можно получить все домены в зоне и сразу получить качественные точки старта для перечисления.
🔗 Пост вдохновлен этой презентацией
Активная DNS-разведка обычно сводится к следующему набору:
Публичные DNS-серверы слушают UDP/53 и принимают запросы со всего интернета. Многие из них перегружены, неправильно настроены, либо намеренно возвращают ложные ответы.
Результат — шум,
NOERROR там, где должен быть NXDOMAIN, и куча мусорных поддоменов.Что лучше?
Запросы напрямую к авторитативному DNS-серверу почти всегда лучше, чем использование публичных рекурсивных резолверов.
Если тебе нужно просто резолвить список поддоменов — используй zdns. Он в целом быстрее и надёжнее , чем dnsx.
Техники для глубокой разведки
В DNS есть промежуточное состояние, которое большинство инструментов игнорирует: Empty Non-Terminals. Они возвращают
NOERROR / NODATA и незаметно показывают, какие ветки иерархии реально существуют. Отлично подходят для поиска скрытых поддеревьев и позволяют избежать бесполезного фаззинга.
NSEC формирует связанный список валидных имён, поэтому обход зоны тривиален с инструментами вроде ldns-walk. NSEC3 хеширует имена, но всё ещё позволяет:
CZDS предоставляет полные файлы зон для множества gTLD. Если твой таргет использует редкий TLD, часто можно получить все домены в зоне и сразу получить качественные точки старта для перечисления.
🔗 Пост вдохновлен этой презентацией
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤5
Распространенные векторы атак race condition в веб-приложениях 🤔
Race condition редко находятся автоматическими сканерами. Это уязвимости не про пэйлоад, а про тайминг, состояние и бизнес-логику.
Проще, когда есть доступ к исходникам. Но на практике багхантер почти всегда работает вслепую — через поведение приложения.
Ниже — два рабочих вектора, которые чаще всего выстреливают💸
HTTP/1.1 last-byte синхронизация
Атака эксплуатирует то, как сервер обрабатывает частично отправленные запросы.
Сценарий:
✅ Открыть первый запрос и удерживать соединение (не отправлять весь контент сразу).
✅ Отправить второй запрос в момент, когда первый ещё обрабатывается.
✅ Добиться перекрытия операций проверки и изменения состояния.
Так ломаются проверки лимитов, купоны, списания и другие бизнес-процессы.
HTTP/2 single-packet атаки
HTTP/2 ускоряет запросы, но даёт атакующему контроль над таймингом.
Сценарий:
✅ Отправлять несколько запросов по одному соединению, удерживая часть данных.
✅ После паузы завершить все запросы одновременно одним TCP-пакетом.
✅ Минимизировать сетевой джиттер и повысить стабильность гонки.
Метод особенно эффективен против логики, не рассчитанной на параллельность.
Что можно сломать
Последствия race condition чаще всего логические:
➖ двойное списание средств;
➖ повторное применение купонов и бонусов;
➖ обход ограничений и лимитов;
➖ неконсистентное состояние данных,
➖ DoS и ошибки контроля доступа,
По импакту такие баги часто уходят в high или critical.
P. S. Для эксплуатации используй Burp Suite Turbo Intruder, а практику оттачивай на Web Security Academy😓
Race condition редко находятся автоматическими сканерами. Это уязвимости не про пэйлоад, а про тайминг, состояние и бизнес-логику.
Проще, когда есть доступ к исходникам. Но на практике багхантер почти всегда работает вслепую — через поведение приложения.
Ниже — два рабочих вектора, которые чаще всего выстреливают
HTTP/1.1 last-byte синхронизация
Атака эксплуатирует то, как сервер обрабатывает частично отправленные запросы.
Сценарий:
Так ломаются проверки лимитов, купоны, списания и другие бизнес-процессы.
HTTP/2 single-packet атаки
HTTP/2 ускоряет запросы, но даёт атакующему контроль над таймингом.
Сценарий:
Метод особенно эффективен против логики, не рассчитанной на параллельность.
Что можно сломать
Последствия race condition чаще всего логические:
По импакту такие баги часто уходят в high или critical.
P. S. Для эксплуатации используй Burp Suite Turbo Intruder, а практику оттачивай на Web Security Academy
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🤔2❤1
Почему в ходе разведке нельзя игнорировать редиректы ❓
Мы привыкли к подходу:
💡 Предположим, во время разведки тебе под руку попался странный ресурс:
⚫️ В имени нет названия компании
⚫️ Но он делает 302-редирект на домен компании
⚫️ Домен не резолвится
Формально он не входит в скоуп, но фактически может являться частью инфраструктуры.
Как помогает urlscan.io
urlscan.io позволяет смотреть на цель как на систему, а не как на один URL. Он показывает:
⚫️ Все редиректы и переходы
⚫️ Домены и IP, с которыми общается страница
⚫️ Загружаемые JS, CSS и сторонние ресурсы
⚫️ Сookies, DOM, JS-переменные
⚫️ Облачные ресурсы, которые не видно через DNS
Таким образом, даже если домен не резолвится, редирект или связанный ресурс всё равно может существовать.
Почему это расширяет скоуп🥳
Когда ты анализируешь редиректы:
✔️ В скоуп попадают активы без прямой связи по имени
✔️ Находятся облачные ресурсы, забытые хосты, dev-стенды
✔️ Появляется возможность связать тот самый непонятный ресурс с целевой организацией
Мы привыкли к подходу:
Есть домен в скоупе — смотрим его. Нет в скоупе — идем дальше.
Что, если подойти к процессу поиска багов в стиле red team?
Формально он не входит в скоуп, но фактически может являться частью инфраструктуры.
Как помогает urlscan.io
urlscan.io позволяет смотреть на цель как на систему, а не как на один URL. Он показывает:
Таким образом, даже если домен не резолвится, редирект или связанный ресурс всё равно может существовать.
Почему это расширяет скоуп
Когда ты анализируешь редиректы:
Иногда самое интересное — между запросами, а не в ответе💲
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2🤔2
В HTTP-запросах почти всегда есть мусор:
автогенерированные заголовки, дубликаты, лишний контекст. Удалять их по одному и каждый раз проверять ответ — слишком долго💤
Header Guardian (Burp Suite) или Squash (Caido) автоматически очистят запросы от ненужных заголовков, оставляя только то, что реально влияет на поведение сервера.
🏃♂️ При активации Squash запускает фоновую задачу, которая:
⚫️ Отправляет исходный запрос
⚫️ Итеративно удаляет параметры запроса, поля формы, JSON и заголовки (включая отдельные файлы cookie)
⚫️ Сравнивает ответы, чтобы выявить инвариантное поведение
⚫️ Сохраняет только те поля, которые необходимы для сохранения исходного ответа
⚫️ Отправляет минимизированный запрос в новую вкладку Replay для просмотра и тестирования
автогенерированные заголовки, дубликаты, лишний контекст. Удалять их по одному и каждый раз проверять ответ — слишком долго
Header Guardian (Burp Suite) или Squash (Caido) автоматически очистят запросы от ненужных заголовков, оставляя только то, что реально влияет на поведение сервера.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19🥴2