Browser HTTP Request Smuggling

Reading time: 3 minutes

브라우저 기반 desync(즉, 클라이언트 측 요청 스머글링)는 피해자의 브라우저를 악용하여 잘못된 프레임의 요청을 공유 연결에 큐잉하여 후속 요청이 다운스트림 구성 요소에 의해 비동기적으로 구문 분석되도록 합니다. 고전적인 FE↔BE 스머글링과 달리, 페이로드는 브라우저가 교차 출처로 합법적으로 보낼 수 있는 것에 의해 제한됩니다.

주요 제약 사항 및 팁

• 브라우저가 탐색, fetch 또는 양식 제출을 통해 방출할 수 있는 헤더 및 구문만 사용하십시오. 헤더 난독화(LWS 트릭, 중복 TE, 잘못된 CL)는 일반적으로 전송되지 않습니다.
• 입력을 반영하거나 응답을 캐시하는 엔드포인트 및 중개자를 타겟으로 하십시오. 유용한 영향에는 캐시 오염, 프론트 엔드 주입 헤더 누출 또는 프론트 엔드 경로/메서드 제어 우회가 포함됩니다.
• 재사용이 중요합니다: 조작된 요청이 고가치 피해자 요청과 동일한 HTTP/1.1 또는 H2 연결을 공유하도록 정렬하십시오. 연결 잠금/상태 유지 동작은 영향을 증폭시킵니다.
• 사용자 정의 헤더가 필요하지 않은 원시 요소를 선호하십시오: 경로 혼란, 쿼리 문자열 주입 및 양식 인코딩된 POST를 통한 본문 형성.
• 재사용 없이 재테스트하거나 HTTP/2 중첩 응답 검사를 사용하여 진정한 서버 측 desync와 단순한 파이프라인 아티팩트를 검증하십시오.

엔드 투 엔드 기술 및 PoC에 대한 내용은 다음을 참조하십시오:

• PortSwigger Research – Browser‑Powered Desync Attacks: https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – client‑side desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync

References

• https://portswigger.net/research/browser-powered-desync-attacks
• https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
• 파이프라인과 스머글링 구분(재사용 허위 긍정에 대한 배경): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling