# HTTP Connection Request Smuggling

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

**Este es un resumen de la publicación** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)

## Ataques de Estado de Conexión <a href="#state" id="state"></a>

### Validación de la Primera Solicitud

Al enrutar solicitudes, los proxies inversos pueden depender del **encabezado Host** para determinar el servidor de back-end de destino, a menudo confiando en una lista blanca de hosts que tienen acceso permitido. Sin embargo, existe una vulnerabilidad en algunos proxies donde la lista blanca solo se aplica a la solicitud inicial en una conexión. En consecuencia, los atacantes podrían explotar esto haciendo primero una solicitud a un host permitido y luego solicitando un sitio interno a través de la misma conexión:
```
GET / HTTP/1.1
Host: [allowed-external-host]

GET / HTTP/1.1
Host: [internal-host]
```
### Enrutamiento de la primera solicitud

En algunas configuraciones, un servidor de front-end puede usar el **encabezado Host de la primera solicitud** para determinar el enrutamiento de back-end para esa solicitud, y luego enrutar de manera persistente todas las solicitudes subsiguientes de la misma conexión de cliente a la misma conexión de back-end. Esto se puede demostrar como:
```
GET / HTTP/1.1
Host: example.com

POST /pwreset HTTP/1.1
Host: psres.net
```
Este problema puede combinarse potencialmente con [Host header attacks](https://portswigger.net/web-security/host-header), como el envenenamiento de restablecimiento de contraseña o [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), para explotar otras vulnerabilidades o obtener acceso no autorizado a hosts virtuales adicionales.

> [!NOTE]
> Para identificar estas vulnerabilidades, se puede utilizar la función 'connection-state probe' en HTTP Request Smuggler.

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