TRACE

Verwendung

Eine TRACE-Anfrage ist ein Diagnosewerkzeug zur Untersuchung der Anfragekette zwischen einem Client und dem Ursprungsserver. Der Server antwortet mit 200 und nimmt die empfangene Anfragenachricht in den Antwortrumpf auf. Ein anerkanntes Format ist Content-Type message/http. Der Antwortrumpf enthält eine Kopie der Anfragenachricht in der empfangenen Form, ausgenommen Felder, die der Server als sensibel einstuft, und erlaubt so den Vergleich mit der ursprünglichen Anfrage.

Eigenschaften

TRACE-Anfragen führen keinen Rumpf mit. Die Clients sind dafür verantwortlich, keine sensiblen Felder wie Zugangsdaten oder Cookies in TRACE-Anfragen aufzunehmen, da die zurückgespiegelte Antwort sämtliche empfangenen Header offenlegt.

Microsoft IIS unterstützte historisch TRACK als proprietären Alias für TRACE. Beide unterliegen derselben XST-Schwachstelle und beide müssen in der Produktion deaktiviert werden.

Erkennung von Zwischenstationen

Wenn eine Anfrage Proxys oder Gateways durchläuft, hängt jede Zwischenstation einen Via-Header-Eintrag an, der die zum Weiterleiten verwendete Protokollversion nennt. Der Vergleich der ursprünglichen Anfrage mit der zurückgespiegelten Kopie zeigt, welche Header von jedem Hop hinzugefügt, geändert oder entfernt wurden.

Der Max-Forwards-Header begrenzt, wie weit eine TRACE-Anfrage läuft. Wird dieser Wert auf null gesetzt, antwortet der erste Proxy, was hilfreich ist, um in einer Kette mit mehreren Hops eine bestimmte Zwischenstation zu isolieren. Das Herunterzählen des Zählers bei jedem Hop verhindert endlose Weiterleitungsschleifen.

Sicherheit und XST

Cross-Site Tracing (XST) ist ein Angriffsvektor, der TRACE ausnutzt, um HTTP-Header einschließlich Authentifizierungs-Token und Cookie-Werten abzugreifen. Ein bösartiges Skript sendet eine TRACE-Anfrage an den Zielserver, und die zurückgespiegelte Antwort legt Header offen, auf die das Skript sonst keinen Zugriff hätte.

Hinweis

Die meisten Produktionsserver deaktivieren TRACE, um XST-Angriffe zu verhindern. Webserver wie Apache und Nginx deaktivieren TRACE standardmäßig. Auch Browser blockieren TRACE. Der WHATWG Fetch Standard führt TRACE als verbotene Methode und verhindert damit, dass JavaScript TRACE-Anfragen absetzt. Das Deaktivieren von TRACE auf dem Server bleibt eine empfohlene Härtungsmaßnahme für alle ins Internet gerichteten Server.

Beispiel

Eine TRACE-Anfrage an die Wurzelressource. Der Server spiegelt die ursprüngliche Anfrage im Antwortrumpf zurück und fügt einen Via-Header hinzu, der zeigt, dass die Anfrage zwei Proxyserver durchlaufen hat.

Anfrage

TRACE / HTTP/1.1
Host: example.com

Antwort

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

Der Via-Header führt proxy1.example.re und proxy2.example.re als Zwischenstationen auf. Beide haben die Anfrage über HTTP/1.1 weitergeleitet. Jede Zwischenstation muss weitergeleiteten Anfragen einen Via-Eintrag anhängen, daher enthält der zurückgespiegelte Rumpf das von den beiden Proxys ergänzte, kumulierte Via-Feld.

CORS

TRACE ist eine von CORS verbotene Methode. Browser blockieren sämtliche Versuche, TRACE über Browser-APIs wie fetch() und XMLHttpRequest zu senden.

TRACE deaktivieren

Apache deaktiviert TRACE mit TraceEnable Off in der Serverkonfiguration. nginx unterstützt TRACE standardmäßig nicht, sodass kein Eingriff nötig ist. Bei IIS muss TRACE (und TRACK) aus den erlaubten Verben im Request Filtering entfernt werden. Caddy unterstützt TRACE standardmäßig nicht.

OWASP empfiehlt, TRACE auf allen Produktionsservern zu deaktivieren. Sicherheitsscanner melden aktiviertes TRACE als Schwachstelle, obwohl moderne Browser TRACE-Anfragen über den Fetch Standard blockieren, der TRACE als verbotene Methode führt.

Das Deaktivieren von TRACE auf Serverebene bleibt die wichtigste Verteidigung gegen XST, weil HTTP-Clients und Skripte außerhalb des Browsers nicht an die Beschränkungen des Fetch Standard gebunden sind.