Теги <a>/<area> могут раскрывать URL-адреса страниц + креды (источник, путь, запрос, фрагмент post-click) с помощью атрибута href="#" с атрибутом ping, указывающим на другое место.

Работает в 🌐 и 🌐 (в Firefox атрибут ping отключён по умолчанию).

При клике браузер отправляет POST-запрос, в заголовке Ping-To указывается URL. referrer-policy игнорируется — доставку ограничивает только директива connect-src в CSP.

Если страница загружена по HTTP или эндпоинт ping находится в том же origin, то ещё отправляется заголовок Ping-From с полным URL (включая фрагмент pre-click).

📌 Пример PoC

InQL v6.1.0: как новая версия делает ее универсальной тулзой для тестирования безопасности GraphQL 🚨

Когда под капотом неизвестный GraphQL-стек, самое затратное — это разведка. InQL 6.1.0 сокращает этот этап до минимума.

Используй Fingerprinter движка InQL в Burp, чтобы за считанные секунды идентифицировать стек GraphQL и избавить себя от проб и ошибок. Разберем эту и другие новые фичи подробнее ⤵️

➡️ Брутфорсер схемы GraphQL (фича вдохновлена CLI-тулзой Clairvoyance Никиты Ступина)

До сих пор InQL был наиболее полезен, когда на сервере была включена функция introspection или когда у тебя уже был файл со схемой GraphQL.

В версии 6.1.0 тулза может попытаться восстановить схему бэкенда, используя подсказки “did you mean…”, поддерживаемые многими реализациями серверов GraphQL.

➡️ GraphQL Server Engine Fingerprinter

Новая версия InQL теперь может определять движок GraphQL, используемый внутренним сервером.

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

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

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

Хотя предыдущие версии InQL отлично подходили для анализа схем, поиска циклических ссылок и определения интересующих точек, создание корректного запроса могло вызывать затруднения.

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

HTML-элемент <geolocation> → новый вектор для эксплуатации XSS 🌐

С января 2026 (Chrome 144+) в браузере официально появился декларативный элемент <geolocation>.

Он задумывался как удобная альтернатива navigator.geolocation, чтобы запросы локации выглядели менее подозрительно и чаще получали разрешение от пользователя.

Новые векторы уже в шпаргалке от PortSwigger:

<geolocation onvalidationstatuschange=alert(1)>
<geolocation autolocate onlocation=alert(1)>
<geolocation onpromptdismiss=alert(1)>
<geolocation onpromptaction=alert(1)>

Разведка Android-приложений: Drozer и анализ версий 📱

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

Лови несколько кейсов, которые часто находят то, что пропускают стандартные тулзы 🔽

1️⃣ Runtime-тестирование IPC через Drozer

Drozer позволяет напрямую взаимодействовать с компонентами Android-приложения: activities, services, broadcast, receivers, content providers.

После установки можно быстро проверить реальную поверхность атаки:

run app.package.attacksurface com.target.app

Дальше — интереснее. Например, можно попробовать запустить экспортированную дебаг activity:

run app.activity.start --component com.target.app com.target.app.DebugActivity

Такие activity иногда обходят авторизацию, раскрывают внутренние данные, дают доступ к скрытым фичам приложения.

2️⃣ Content provider → SQL-инъекция

Content providers часто работают как база данных между приложениями. Если provider экспортирован, можно потестить пэйлоад для SQLi:

run app.provider.query content://com.target.app.provider/users --projection "* FROM users; --"

3️⃣ Broadcast injection

Некоторые приложения слушают системные broadcast-события. Если действие не защищено, его может вызвать любое приложение:

run app.broadcast.send --action com.target.app.PRIVILEGED_ACTION --extra string key value

Так иногда удаётся триггерить фичи, которые разработчики считали внутренними.

4️⃣ Сравнение версий для анализа регрессий безопасности

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

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

Быстрый способ посмотреть изменения:

apktool d target_v1.0.apk -o v1
apktool d target_v1.1.apk -o v2
diff -r v1/ v2/

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

Посты по теме:
🔗 Первичный анализ любого APK-файла: советы багхантеру
🔗 Упрощаем обработку приложений APK / XAPK / APKM / DEX / JAR / WAR с помощью BFScan
🔗 Реверс приложений на Flutter

Эксплуатация NoSQLi с помощью массивов параметров 💨

Если приложение не принимает JSON и работает только с application/x-www-form-urlencoded, это не защита от NoSQL-инъекций.

Многие серверные либы автоматически преобразуют параметры вида:

username[$ne]=1

в объект:

{ username: { $ne: 1 } }

Таким образом, можно передавать NoSQL-операторы через обычные параметры формы 🔥

Ключевое:
➡️ Парсер на сервере преобразует массивы в объекты
➡️ Ограничение по Content-Type не спасает от инъекции
➡️ NoSQL-операторы можно внедрять без JSON