💡 HTTP request smuggling — атака, направленная на рассинхронизацию фронтенд- и бэкенд-сервера, в результате которой можно внедрить HTTP-запрос мимо фронтенд-сервера. В результате успешной эксплуатации можно сдать критическую багу 🤑
Request smuggling в первую очередь связана с запросами HTTP/1, но некоторые приложения, поддерживающие HTTP/2, также могут быть уязвимы в зависимости от внутренней архитектуры.
При наличии уязвимой конфигурации CL.TE фронтенд-сервер использует заголовок Content-Length, а бэкенд-сервер — Transfer-Encoding:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
💡 Как обнаружить баги типа CL.TE
1. Отправляем запрос в Burp Repeater.
• Понижаем версию протокола до HTTP/1.1.
• Отключаем опцию
Update Content-Length.• Устанавливаем заголовок
Content-Length в значение 6.• Добавляем заголовок
Transfer-Encoding: chunked.• Отправляем chunk с некорректным размером.
Если сервер на бэкенде уходит в тайм-аут, это может указывать на потенциально уязвимую конфигурацию CL.TE.
💡 Подтверждаем через дифференцированные ответы
2. Формируем и отправляем вредоносный запрос:
• Заменяем предыдущий chunk на завершающий (terminating) chunk.
• Добавляем контрабандный запрос после тела chunked-запроса.
• Добавляем строку
X-ignore: X (без перевода строки в конце) и отправляем.3. Сразу после вредоносного отправляем обычный запрос в Repeater и понижаем его до HTTP/1.1.
Если в ответ на обычный запрос приходит 404 вместо 200, значит — бэкенд был «отравлен»!
👉 Потренироваться на лабораторной работе PortSwigger