TRACE
사용법
TRACE 요청은 클라이언트와 오리진 서버 사이의 요청 경로를 살펴보기 위한 진단 도구입니다. 서버는 200으로 응답하며 수신한 요청 메시지를 응답 본문에 포함합니다. 인정되는 형식 중 하나는 Content-Type message/http입니다. 응답 본문에는 서버가 민감하다고 판단한 필드를 제외하고 수신한 그대로의 요청 메시지 사본이 담기므로, 원래 요청과 비교해 볼 수 있습니다.
특성
TRACE 요청에는 본문이 없습니다. 되돌아온 응답이 수신된 모든 헤더를 노출하므로, 자격 증명이나 쿠키 같은 민감한 필드를 TRACE 요청에 포함하지 않는 것은 클라이언트의 책임입니다.
Microsoft IIS는 역사적으로 TRACE의 독자적인 별칭으로 TRACK을 지원했습니다. 둘 다 동일한 XST 취약점의 대상이며, 운영 환경에서는 둘 다 비활성화해야 합니다.
중계자 탐지
요청이 프록시나 게이트웨이를 거치면 각 중계자가 전달에 사용한 프로토콜 버전을 나열하는 Via 헤더 항목을 덧붙입니다. 원래 요청과 되돌아온 사본을 비교하면 각 홉에서 추가·수정·제거된 헤더가 드러납니다.
Max-Forwards 헤더는 TRACE 요청이 얼마나 멀리까지 전달될지 제한합니다. 이 값을 0으로 설정하면 첫 번째 프록시가 응답하므로, 여러 홉으로 이루어진 경로에서 특정 중계자를 분리해 살펴보는 데 유용합니다. 각 홉에서 이 카운터를 하나씩 줄이면 무한 전달 루프를 막을 수 있습니다.
보안과 XST
Cross-Site Tracing(XST)은 TRACE를 악용해 인증 토큰과 쿠키 값을 포함한 HTTP 헤더를 가로채는 공격 벡터입니다. 악성 스크립트가 대상 서버로 TRACE 요청을 보내면, 되돌아온 응답이 평소에는 그 스크립트가 접근할 수 없는 헤더를 노출합니다.
참고
대부분의 운영 서버는 XST 공격을 막기 위해 TRACE를 비활성화합니다. Apache와 nginx 같은 웹 서버는 기본적으로 TRACE를 비활성화합니다. 브라우저도 TRACE를 차단합니다. WHATWG Fetch Standard는 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.reVia 헤더는 proxy1.example.re와 proxy2.example.re를 중계자로 나열합니다. 둘 다 HTTP/1.1로 요청을 전달했습니다. 각 중계자는 전달하는 요청에 Via 항목을 덧붙여야 하므로, 되돌아온 본문에는 두 프록시가 추가한 누적 Via 필드가 포함됩니다.
CORS
TRACE는 CORS 금지 메서드입니다. 브라우저는 fetch()나 XMLHttpRequest 같은 브라우저 API로 TRACE를 보내려는 모든 시도를 차단합니다.
TRACE 비활성화
Apache는 서버 설정에서 TraceEnable Off로 TRACE를 비활성화합니다. nginx는 기본적으로 TRACE를 지원하지 않으므로 조치가 필요 없습니다. IIS에서는 Request Filtering의 허용 동사 목록에서 TRACE(와 TRACK)를 제거해야 합니다. Caddy는 기본적으로 TRACE를 지원하지 않습니다.
OWASP는 모든 운영 서버에서 TRACE를 비활성화할 것을 권장합니다. 현대 브라우저가 Fetch Standard를 통해 TRACE 요청을 차단하고 그 표준이 TRACE를 금지된 메서드로 분류하고 있음에도, 보안 스캐너는 활성화된 TRACE를 취약점으로 표시합니다.
브라우저가 아닌 HTTP 클라이언트와 스크립트는 Fetch Standard의 제약을 받지 않으므로, 서버 수준에서 TRACE를 비활성화하는 것이 여전히 XST에 대한 주된 방어책입니다.