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 %}

This is a summary of the post https://portswigger.net/research/browser-powered-desync-attacks

Connection State Attacks

First-request Validation

When routing requests, reverse proxies might depend on the Host header to determine the destination back-end server, often relying on a whitelist of hosts that are permitted access. However, a vulnerability exists in some proxies where the whitelist is only enforced on the initial request in a connection. Consequently, attackers could exploit this by first making a request to an allowed host and then requesting an internal site through the same connection:

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

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

First-request Routing

In some configurations, a front-end server may use the Host header of the first request to determine the back-end routing for that request, and then persistently route all subsequent requests from the same client connection to the same back-end connection. This can be demonstrated as:

GET / HTTP/1.1
Host: example.com

POST /pwreset HTTP/1.1
Host: psres.net

This issue can potentially be combined with Host header attacks, such as password reset poisoning or web cache poisoning, to exploit other vulnerabilities or gain unauthorized access to additional virtual hosts.

{% hint style="info" %} To identify these vulnerabilities, the 'connection-state probe' feature in HTTP Request Smuggler can be utilized. {% endhint %}