TRACE

Utilisation

Une requête TRACE est un outil de diagnostic destiné à inspecter la chaîne de requête entre un client et le serveur d’origine. Le serveur répond 200 et inclut dans le corps de la réponse le message de requête reçu. Un format reconnu est Content-Type message/http. Le corps de la réponse contient une copie du message de requête tel qu’il a été reçu, à l’exclusion des champs que le serveur juge sensibles, ce qui permet la comparaison avec la requête d’origine.

Propriétés

Les requêtes TRACE ne transportent pas de corps. Il revient aux clients de ne pas inclure de champs sensibles tels que des identifiants ou des cookies dans les requêtes TRACE, puisque la réponse renvoyée en écho expose tous les en-têtes reçus.

Microsoft IIS a historiquement pris en charge TRACK comme alias propriétaire de TRACE. Les deux sont exposés à la même vulnérabilité XST et les deux doivent être désactivés en production.

Détection des intermédiaires

Lorsqu’une requête traverse des proxys ou des passerelles, chaque intermédiaire ajoute une entrée dans l’en-tête Via indiquant la version du protocole utilisée pour le relais. Comparer la requête d’origine à la copie renvoyée en écho révèle les en-têtes ajoutés, modifiés ou supprimés par chaque saut.

L’en-tête Max-Forwards limite la distance parcourue par une requête TRACE. Fixer cette valeur à zéro fait répondre le premier proxy, ce qui est utile pour isoler un intermédiaire précis dans une chaîne à plusieurs sauts. La décrémentation du compteur à chaque saut empêche les boucles de relais infinies.

Sécurité et XST

Le Cross-Site Tracing (XST) est un vecteur d’attaque qui exploite TRACE pour capturer des en-têtes HTTP, y compris des jetons d’authentification et des valeurs de cookie. Un script malveillant envoie une requête TRACE au serveur ciblé, et la réponse renvoyée en écho expose des en-têtes autrement inaccessibles au script.

Remarque

La plupart des serveurs de production désactivent TRACE afin de prévenir les attaques XST. Des serveurs web tels qu’Apache et Nginx désactivent TRACE par défaut. Les navigateurs bloquent eux aussi TRACE. Le WHATWG Fetch Standard classe TRACE parmi les méthodes interdites, empêchant JavaScript d’émettre des requêtes TRACE. Désactiver TRACE côté serveur reste une mesure de durcissement recommandée pour tous les serveurs exposés à Internet.

Exemple

Une requête TRACE vers la ressource racine. Le serveur renvoie en écho la requête d’origine dans le corps de la réponse et inclut un en-tête Via montrant que la requête a traversé deux serveurs proxy.

Requête

TRACE / HTTP/1.1
Host: example.com

Réponse

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

L’en-tête Via répertorie proxy1.example.re et proxy2.example.re comme intermédiaires. Tous deux ont relayé la requête en HTTP/1.1. Chaque intermédiaire doit ajouter une entrée Via aux requêtes relayées : le corps renvoyé en écho contient donc le champ Via cumulé ajouté par les deux proxys.

CORS

TRACE est une méthode interdite par CORS. Les navigateurs bloquent toute tentative d’envoyer TRACE via des API de navigateur telles que fetch() et XMLHttpRequest.

Désactiver TRACE

Apache désactive TRACE avec TraceEnable Off dans la configuration du serveur. nginx ne prend pas en charge TRACE par défaut : aucune action n’est donc nécessaire. IIS impose de retirer TRACE (et TRACK) des verbes autorisés dans Request Filtering. Caddy ne prend pas en charge TRACE par défaut.

OWASP recommande de désactiver TRACE sur tous les serveurs de production. Les scanners de sécurité signalent TRACE activé comme une vulnérabilité, même si les navigateurs modernes bloquent les requêtes TRACE via le Fetch Standard, qui classe TRACE parmi les méthodes interdites.

Désactiver TRACE au niveau du serveur demeure la principale défense contre le XST, car les clients HTTP et les scripts hors navigateur ne sont pas soumis aux restrictions du Fetch Standard.