🛠 Attack vectors of the TRACE method
Salute, I often ask the guys I meet who know how to use DAST and have at least touched the API in some way, about the TRACE method and I see that they barely touch on it.
I think it’s worth sharing with you a description of the problems. Let us immediately note that the method is diagnostic and is considered unsafe, so it is disabled, but there are also flaws when it is used or it was simply forgotten, not checked, or “historically”.
Description of the method
TRACE performs a loop-back test where the server returns to the client an exact copy of the received HTTP request with headers (Content-Type and body). Originally used to debug proxy chains to track changing headers. Example when a request was returned, including cookies and headers:
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
Flags by code
• 2xx and especially with header reflection are considered exploitable
• 4xx/ 5xx type 405/ 501, that is, the method is disabled/not implemented. As an example, if the server accepts TRACE and processes it in the same way as regular requests, an attacker can use TRACE requests as “garbage” traffic to hit the 429 Too Many Requeste limit
Attack vectors
• Cross‑Site Tracing (XST) to steal cookies/tokens. OWASP describes bypassing HttpOnly and stealing session cookies via a TRACE response. TRACE is used to bypass HttpOnly‑cookies and read content. HttpOnly prohibits JS passage to cookies (XSS is not valid), but if the browser sends cookies in HTTP headers, then a vulnerable scenario: a cookie is added to the request, then in the browser response they are displayed in the body, where the attacker, through another vulnerability (another XSS / browser bug / cross-domain) receives this body
• XST + XSS/CSRF to perform actions on behalf of a victim or other client-side vulnerabilities: The XSS/CSRF script initiates a TRACE request to the same domain, where the Cookie and authorization headers are included in the response body. As a result, the script steals data and uses it to log into the victim’s account. Here a token/session is mined, even if they are protected by HttpOnly
• TRACE for HTTP‑desync/cache‑poisoning attacks: TRACE allows you to see the final form of the request after all modifications to the proxy. We understand that it is used as an echo request, where it is clear that it goes to the backend and as a result, it results in substitution of responses (cache poisoning), theft, execution of requests on behalf of other users
Example
1 - Checking the existence of a method
curl -i -X TRACE https://target.example/
2 - Answer
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
Therefore, the token and cookie can be used to personalize on behalf of the client and the internal headers, IP, reveal the structure of the infrastructure (perimeter, segmentation, internal services).
Total: classic XST is considered obsolete, but TRACE is still included on some servers (Apache, etc.) and is capable of revealing internal headers and infrastructure structure, as well as working in conjunction with SSRF/ RCE, etc. PortSwigger and OWASP continue to reference TRACE validation tests in their HTTP method security checklists for precisely these reasons.
#appsec #toolchain #reco #specialty #research