🛠 Вектора атак метода TRACE

Салют, часто спрашиваю встречающихся ребят, кто умеет в DAST и хоть как то трогал API, про метод TRACE и наблюдаю картину, что поверхностно касаются его.

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

Описание метода

TRACE выполняет loop‑back‑тест, когда сервер возвращает клиенту точную копию полученного HTTP‑запроса с заголовками (Content-Type и тело). Изначально использовался для отладки прокси‑цепочек для отслеживания изменяющихся заголовков. Пример, когда вернулся запрос, включая cookies и заголовки:

TRACE / HTTP/1.1

Host: vulnerable.example

User-Agent: test-client

Cookie: SESSIONID=abc123; HttpOnly

HTTP/1.1 200 OK

Content-Type: message/http

TRACE / HTTP/1.1

Host: vulnerable.example

User-Agent: test-client

Cookie: SESSIONID=abc123; HttpOnly

Флаги по кодам

• 2xx и особенно с отражением заголовков считаем эксплуатируемыми

• 4xx/ 5xx типа 405/ 501, то есть метод отключён/ не реализован. Как пример, если сервер принимает TRACE и обрабатывает его так же, как обычные запросы, атакующий может использовать TRACE‑запросы как «мусорный» трафик для выбивания лимита по 429 Too Many Requeste

Вектора атак

• Cross‑Site Tracing (XST) для кражи cookies / токенов. OWASP описывает обход HttpOnly и кражу сессионных cookies через TRACE‑ответ. TRACE используется для обхода HttpOnly‑cookies и чтения содержимого. HttpOnly запрещает проход JS к cookie (XSS не валидна), но если браузер отправляет cookie в HTTP‑заголовках, то уязвимый сценарий: добавляется cookie в запрос, далее в ответе браузера они отображаются в теле, где злоумышленник через другую уязвимость (иной XSS / browser bug / кросс‑домен) получает это тело

• XST + XSS/ CSRF для выполнения действий от имени жертвы или иными клиентскими уязвимостями: XSS/ CSRF‑скрипт инициирует TRACE‑запрос к тому же домену, где Cookie и заголовки авторизации попадают в тело ответа. Вследствии скрипт крадёт данные и использует, что бы осуществить вход в аккаунт жертвы. Тут добывается токен/ сессия, даже если они защищены HttpOnly

• TRACE для HTTP‑desync/ cache‑poisoning атак: TRACE позволяет увидеть финальный вид запроса после всех модификаций на прокси. Мы понимаем, что он используется как эхо запрос, где видно, что идет до бэкенда и вследствии получается подмена ответов (cache poisoning), кража, выполнение запросов от имени других пользователей

Пример

1 - Проверка наличия метода

curl -i -X TRACE https://target.example/

2 - Ответ

HTTP/1.1 200 OK

Content-Type: message/http

Content-Length: 192

TRACE / HTTP/1.1

Host: internal.example

User-Agent: corp-client/5.2

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

X-Forwarded-For: 10.0.5.34

X-Internal-User: 123456

Cookie: SESSIONID=abc123; HttpOnly

Следовательно, токен и cookie можно использовать для персонификации от имени клиента и внутренние заголовки, IP раскрывают структуру инфраструктуры (периметр, сегментация, внутренние сервисы).

Итого: классический XST считается устаревшим, но TRACE до сих пор включён на части серверов (Apache и пр.) и способен раскрывать внутренние заголовки и структуру инфраструктуры, а также работать в связке с SSRF/ RCE и т.д. PortSwigger и OWASP продолжают ссылаться на тесты проверки TRACE в своих чек‑листах безопасности HTTP‑методов именно по этим причинам.

#appsec #toolchain #reco #specialty #reserch