HTTP Connection Request Smuggling

이 페이지는 Browser-Powered Desync Attacks에 대한 PortSwigger의 기초 연구를 요약, 확장 및 업데이트합니다. 또한 HTTP/2 연결 상태 남용에 대한 후속 작업을 다룹니다. 이 페이지는 TCP/TLS 연결당 한 번만 원본이 결정되는 취약점에 초점을 맞추고 있으며, 이를 통해 공격자는 채널이 설정된 후 다른 내부 호스트로 요청을 “밀어넣을” 수 있습니다.

Connection-State Attacks

First-request Validation

요청을 라우팅할 때, 리버스 프록시는 Host (또는 HTTP/2의 :authority) 헤더에 의존하여 목적지 백엔드 서버를 결정할 수 있으며, 종종 접근이 허용된 호스트의 화이트리스트에 의존합니다. 그러나 여러 프록시에서 화이트리스트가 연결의 첫 번째 요청에서만 적용되는 취약점이 존재합니다. 결과적으로, 공격자는 허용된 요청을 먼저 전송한 후 동일한 기본 연결을 재사용하여 내부 가상 호스트에 접근할 수 있습니다:

GET / HTTP/1.1
Host: allowed-external-host.example

GET /admin HTTP/1.1
Host: internal-only.example

First-request Routing

많은 HTTP/1.1 리버스 프록시는 전달하는 첫 번째 요청에만 기반하여 아웃바운드 연결을 백엔드 풀에 매핑합니다. 동일한 프론트엔드 소켓을 통해 전송되는 모든 후속 요청은 Host 헤더와 관계없이 조용히 재사용됩니다. 이는 비밀번호 재설정 중독 또는 웹 캐시 중독과 같은 고전적인 Host 헤더 공격과 결합되어 다른 가상 호스트에 대한 SSRF와 유사한 접근을 얻을 수 있습니다:

GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal

2023-2025의 새로운 내용 – HTTP/2/3 연결 집합 남용

현대 브라우저는 인증서, ALPN 프로토콜 및 IP 주소가 일치할 때 HTTP/2 및 HTTP/3 요청을 단일 TLS 연결로 집합합니다. 프론트엔드가 첫 번째 요청만 승인하는 경우, 이후의 모든 집합 요청은 해당 승인을 상속받습니다 – 호스트/:authority가 변경되더라도.

악용 시나리오

1. 공격자는 evil.com을 제어하며, 이는 대상 internal.company와 동일한 CDN 엣지 노드로 해석됩니다.
2. 피해자의 브라우저는 이미 evil.com에 대한 열린 HTTP/2 연결을 가지고 있습니다.
3. 공격자는 자신의 페이지에 숨겨진 <img src="https://internal.company/…">를 삽입합니다.
4. 연결 매개변수가 일치하므로 브라우저는 기존 TLS 연결을 재사용하고 internal.company에 대한 요청을 다중화합니다.
5. CDN/라우터가 첫 번째 요청만 검증했다면 내부 호스트가 노출됩니다.

Chrome/Edge/Firefox에 대한 PoC는 James Kettle의 발표 “HTTP/2: The Sequel is Always Worse” (Black Hat USA 2023)에서 확인할 수 있습니다.

도구

• Burp Suite 2023.12는 자동으로 집합 및 TE/CL 기술을 시도하는 실험적 HTTP/2 Smuggler 삽입 지점을 도입했습니다.
• smuggleFuzz (https://github.com/microsoft/smugglefuzz) – HTTP/2 및 HTTP/3에서 프론트엔드/백엔드 비동기 벡터를 무차별 대입하기 위해 2024년에 출시된 Python 프레임워크입니다.

완화 조치

• 항상 모든 요청에서 Host/:authority를 재검증하고, 연결 생성 시에만 검증하지 마십시오.
• CDN/로드 밸런서 계층에서 원본 집합을 비활성화하거나 엄격하게 범위를 지정하십시오 (예: NGINX에서 http2_origin_cn 끄기).
• 브라우저가 합법적으로 집합할 수 없도록 내부 및 외부 호스트 이름에 대해 별도의 인증서 또는 IP 주소를 배포하십시오.
• 가능한 경우 각 요청 후에 connection: close 또는 proxy_next_upstream을 선호하십시오.

실제 사례 (2022-2025)

탐지 요약

1. 동일한 TCP/TLS 연결에서 서로 다른 Host 또는 :authority 헤더로 두 개의 요청을 보냅니다.
2. 두 번째 응답이 첫 번째 호스트(안전)에서 발생하는지 아니면 두 번째 호스트(취약)에서 발생하는지 관찰합니다.
3. Burp에서: Repeat → keep-alive → Send → Follow.
4. HTTP/2를 테스트할 때, 무해한 호스트에 대해 전용 스트림(ID 1)을 열고, 내부 호스트에 대해 두 번째 스트림(ID 3)을 다중화하여 응답을 찾습니다.

참고 문헌

• PortSwigger Research – HTTP/2: The Sequel is Always Worse (Black Hat USA 2023)
• Envoy Security Advisory CVE-2024-2470 – 부적절한 권한 검증