HTTP Connection Request Smuggling

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

이것은 게시물의 요약입니다 https://portswigger.net/research/browser-powered-desync-attacks

Connection State Attacks

First-request Validation

요청을 라우팅할 때, 리버스 프록시는 Host header에 의존하여 목적지 백엔드 서버를 결정할 수 있으며, 종종 접근이 허용된 호스트의 화이트리스트에 의존합니다. 그러나 일부 프록시에서는 화이트리스트가 연결의 초기 요청에만 적용되는 취약점이 존재합니다. 결과적으로 공격자는 먼저 허용된 호스트에 요청을 한 다음 동일한 연결을 통해 내부 사이트를 요청함으로써 이를 악용할 수 있습니다:

GET / HTTP/1.1
Host: [allowed-external-host]

GET / HTTP/1.1
Host: [internal-host]

First-request Routing

일부 구성에서는 프론트엔드 서버가 첫 번째 요청의 Host 헤더를 사용하여 해당 요청의 백엔드 라우팅을 결정한 다음, 동일한 클라이언트 연결의 모든 후속 요청을 동일한 백엔드 연결로 지속적으로 라우팅할 수 있습니다. 이는 다음과 같이 설명할 수 있습니다:

GET / HTTP/1.1
Host: example.com

POST /pwreset HTTP/1.1
Host: psres.net

이 문제는 Host header attacks와 결합될 수 있으며, 예를 들어 비밀번호 재설정 중독 또는 web cache poisoning과 같은 공격을 통해 다른 취약점을 악용하거나 추가 가상 호스트에 대한 무단 액세스를 얻을 수 있습니다.

{% hint style="info" %} 이러한 취약점을 식별하기 위해 HTTP Request Smuggler의 'connection-state probe' 기능을 활용할 수 있습니다. {% endhint %}