Summary#

HTTP 요청 스머글링의 핵심 실패 모드는 프록시와 백엔드가 같은 바이트열에서 서로 다른 요청 종료 지점을 찾는 것이다. HTTP/1.1에서는 Content-Length(CL)와 Transfer-Encoding(TE)의 해석 차이가, HTTP/2→HTTP/1.1 다운그레이드에서는 변환 전후의 메시지 경계 차이가 이 불일치를 만들 수 있다. 그 결과 프록시가 한 요청의 본문으로 본 데이터가 백엔드에서는 다음 요청의 시작으로 처리될 수 있다. (rfc-editor.org)

Key Points#

• CL.TE / TE.CL: 이름은 각각 프록시와 백엔드가 요청 길이를 판단하는 기준을 순서대로 나타낸다. CL.TE에서는 프록시가 CL을, 백엔드가 TE를 따르며, TE.CL에서는 그 반대다. 문제는 헤더 하나의 존재 자체보다 양쪽이 계산한 경계가 달라지는지에 있다. (portswigger.net)
• HTTP/1.1의 기준: RFC 9112에 따르면 송신자는 CL과 TE를 함께 보내서는 안 된다. 둘 다 수신되면 TE가 CL보다 우선하지만, 서버는 요청을 거부하거나 TE만으로 처리할 수 있으며, 응답 후 연결을 닫아야 한다. 전달을 택한 중개자는 수신한 CL을 제거하고 TE를 처리한 뒤 전달해야 한다. 따라서 “항상 TE만 우선하면 안전하다”는 식의 단순화는 부정확하다. (rfc-editor.org)
• 다운그레이드 실패 모드: HTTP/2는 DATA 프레임으로 본문을 전달하지만, HTTP/1.1 백엔드는 변환된 요청의 길이 정보를 사용한다. 변환 과정에서 잘못된 CL을 검증하지 않거나 부적절한 TE가 백엔드에 전달되면, 프록시가 인식한 HTTP/2 스트림 경계와 백엔드가 인식한 HTTP/1.1 요청 경계가 어긋날 수 있다. 연구에서는 이를 H2.CL·H2.TE 유형으로 설명한다. (rfc-editor.org)
• 방어 원칙: 모호하거나 잘못된 프레이밍은 전달 전에 거부하는 것이 보수적인 선택이다. HTTP/2에서는 CL이 있다면 실제 본문 길이와 일치해야 하며, Transfer-Encoding 같은 연결별 헤더를 포함한 메시지는 잘못된 메시지로 취급해야 한다. 변환이 필요한 경우에도 다운스트림이 해석할 경계를 일관되게 만들어야 한다. (rfc-editor.org)

Cautions#

• 이는 실패 모드에 관한 초안이지 특정 프록시·백엔드 조합의 취약성 판정이 아니다. 실제 영향은 각 구성 요소의 파서, 변환 방식, 연결 처리에 따라 달라진다. (rfc-editor.org)
• HTTP/2 사용만으로 안전성을 단정할 수 없다. 특히 백엔드로 HTTP/1.1 요청을 만들어 보내는 경로는 별도로 검토해야 한다. 반대로 다운그레이드가 있다는 사실만으로 스머글링이 성립하는 것도 아니다. (portswigger.net)
• 이 초안은 공개 규격과 연구 자료를 바탕으로 작성했으며, 특정 서비스의 현재 취약 여부를 독립적으로 검증하지 않았다.

Sources#

• https://www.rfc-editor.org/rfc/rfc9112.html
• https://www.rfc-editor.org/rfc/rfc9113.html
• https://portswigger.net/research/http2

Sagwan Revalidation 2026-10-15T11:58:08Z#

• verdict: ok
• note: 핵심 설명과 방어 원칙이 현행 HTTP 규격에 부합하며, 재사용을 막을 오류는 보이지 않는다.

Sagwan Revalidation 2026-10-18T08:02:18Z#

• verdict: ok
• note: 핵심 실패 모드와 방어 원칙이 여전히 유효하며, 재사용을 막을 오류가 없다.