TRACE

Применение

Запрос TRACE — это диагностический инструмент для исследования цепочки передачи запроса между клиентом и сервером-источником. Сервер отвечает кодом 200 и включает полученное сообщение запроса в тело ответа. Один из признанных форматов — Content-Type message/http. Тело ответа содержит копию сообщения запроса в том виде, в каком оно было получено, за исключением полей, которые сервер считает конфиденциальными, что позволяет сравнить её с исходным запросом.

Свойства

Запросы TRACE не содержат тела. Клиенты обязаны не включать в запросы TRACE конфиденциальные поля, такие как учётные данные или Cookie, поскольку отражённый ответ раскрывает все полученные заголовки.

Microsoft IIS исторически поддерживал TRACK как проприетарный псевдоним для TRACE. Оба подвержены одной и той же уязвимости XST, и оба необходимо отключать в продакшене.

Обнаружение промежуточных узлов

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

Заголовок Max-Forwards ограничивает, насколько далеко продвигается запрос TRACE. Установка этого значения в ноль приводит к тому, что отвечает первый прокси, — это удобно для выявления конкретного промежуточного узла в многозвенной цепочке. Уменьшение счётчика на каждом переходе предотвращает бесконечные циклы пересылки.

Безопасность и XST

Межсайтовая трассировка (Cross-Site Tracing, XST) — это вектор атаки, использующий TRACE для перехвата HTTP-заголовков, включая токены аутентификации и значения cookie. Вредоносный скрипт отправляет запрос TRACE на целевой сервер, и отражённый ответ раскрывает заголовки, которые иначе скрипту недоступны.

Примечание

Большинство продакшен-серверов отключают TRACE, чтобы предотвратить атаки XST. Веб-серверы, такие как Apache и Nginx, отключают TRACE по умолчанию. Браузеры также блокируют TRACE. Стандарт WHATWG Fetch относит TRACE к запрещённым методам, не давая JavaScript отправлять запросы TRACE. Отключение TRACE на сервере остаётся рекомендуемой мерой усиления защиты для всех серверов, доступных из интернета.

Пример

Запрос TRACE к корневому ресурсу. Сервер отражает исходный запрос в теле ответа и включает заголовок Via, показывающий, что запрос прошёл через два прокси-сервера.

Запрос

TRACE / HTTP/1.1
Host: example.com

Ответ

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 91
Via: 1.1 proxy1.example.re, 1.1 proxy2.example.re

TRACE / HTTP/1.1
Host: example.com
Via: 1.1 proxy1.example.re, 1.1 proxy2.example.re

Заголовок Via перечисляет proxy1.example.re и proxy2.example.re в качестве промежуточных узлов. Оба переслали запрос по HTTP/1.1. Каждый промежуточный узел обязан добавлять запись Via в пересылаемые запросы, поэтому отражённое тело содержит накопленное поле Via, сформированное двумя прокси.

CORS

TRACE относится к запрещённым в CORS методам. Браузеры блокируют любые попытки отправить TRACE через браузерные API, такие как fetch() и XMLHttpRequest.

Отключение TRACE

Apache отключает TRACE директивой TraceEnable Off в конфигурации сервера. nginx по умолчанию не поддерживает TRACE, поэтому никаких действий не требуется. В IIS нужно удалить TRACE (и TRACK) из списка разрешённых глаголов в фильтрации запросов (Request Filtering). Caddy по умолчанию не поддерживает TRACE.

OWASP рекомендует отключать TRACE на всех продакшен-серверах. Сканеры безопасности отмечают включённый TRACE как уязвимость, даже несмотря на то, что современные браузеры блокируют запросы TRACE согласно стандарту Fetch, который относит TRACE к запрещённым методам.

Отключение TRACE на уровне сервера остаётся главной защитой от XST, поскольку небраузерные HTTP-клиенты и скрипты не связаны ограничениями стандарта Fetch.