# HTTP Connection Request Smuggling

{{#include ../banners/hacktricks-training.md}}

**This is a summary of the post** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)

## Connection State Attacks <a href="#state" id="state"></a>

### 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](https://portswigger.net/web-security/host-header), such as password reset poisoning or [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), to exploit other vulnerabilities or gain unauthorized access to additional virtual hosts.

> [!TIP]
> To identify these vulnerabilities, the 'connection-state probe' feature in HTTP Request Smuggler can be utilized.

{{#include ../banners/hacktricks-training.md}}