29. HTTP Request Smuggling 감 잡기

요청 스머글링은 프록시와 백엔드가 하나의 바이트 스트림에서 요청의 끝을 다르게 정할 때 생긴다. Content-Length와 Transfer-Encoding의 충돌은 대표적인 원인이지만, 문제의 본질은 헤더 이름 하나가 아니라 서로 다른 HTTP 파서와 연결 재사용의 조합이다. 실험은 격리된 랩과 승인된 CTF에서만 진행한다.

먼저 경로와 파서를 식별한다

클라이언트에서 CDN·로드밸런서·리버스 프록시·애플리케이션까지 연결 경로를 그린다. 각 계층의 HTTP 버전, hop-by-hop 헤더 처리, 비정상 요청의 거부 정책, 백엔드 연결 재사용을 문서화한다. 프록시 로그와 백엔드 로그의 요청 ID·메서드·경로·본문 길이를 비교하면 경계 불일치를 찾는 데 도움이 된다.

검증은 무해한 두 번째 요청과 전용 백엔드로 시작한다. 정상 요청의 기준선, 잘못된 길이의 단일 요청, 충돌하는 framing을 각각 분리해 보내고, 연결이 멈추거나 다음 정상 요청의 응답이 바뀌는지만 관찰한다. 운영 사용자 연결에 섞일 수 있는 도구나 지속적인 스캔은 사용하지 않는다. 응답 혼합은 의심 신호이지 취약성의 확정이 아니므로 서버 로그와 패킷 캡처로 원인을 교차 확인한다.

방어의 우선순위

가장 좋은 방어는 앞단과 뒷단이 동일한 엄격한 파싱 규칙을 사용하게 하는 것이다. 충돌하는 Content-Length·Transfer-Encoding, 중복 길이 헤더, 비정상 공백과 잘린 chunk를 경계에서 거부하고, 프록시가 hop-by-hop 헤더를 정리하도록 한다. HTTP/2를 HTTP/1.1로 변환하는 지점도 별도의 테스트 대상으로 삼는다.

수정 후에는 keep-alive와 오류 경로를 포함한 회귀 테스트를 돌린다. 스머글링은 단순히 400을 반환하는지보다, 한 요청이 다음 요청의 해석에 영향을 주지 않는지로 판정해야 한다.