HTTP request smuggling (o encubrimiento de solicitudes HTTP) es una técnica de
ataque que explota diferencias en la forma en que los servidores (por ejemplo, un proxy y
un backend) interpretan las solicitudes HTTP, especialmente cuando están en cadena.
¿Qué ocurre?
POST / HTTP/1.1
Host: [Link]
Content-Length: 58
Transfer-Encoding: chunked
GET /resources/js/[Link] HTTP/1.1
X-Ignore: ignored
El atacante envía una única solicitud manipulada que es interpretada de forma
diferente por los distintos componentes (como el proxy y el servidor final). Esto puede
permitir que:
• Se inyecten solicitudes ocultas al backend.
• Se omitan controles de seguridad del proxy.
• Se cause desincronización entre el proxy y el backend.
¿Cómo lo logra?
Manipulando encabezados como:
• Content-Length
• Transfer-Encoding
Por ejemplo, si un proxy usa Content-Length y el backend usa Transfer-Encoding, podrían
interpretar distinto el final de la solicitud.
¿Qué impacto puede tener?
• Bypassing de firewalls o WAFs
• Cache poisoning
• Robo de sesiones
• Ejecución de comandos ocultos
En resumen:
HTTP request smuggling es un ataque que aprovecha la diferencia en la interpretación de
solicitudes HTTP entre servidores para ocultar tráfico malicioso o manipular cómo se
procesan las solicitudes.
You said:
This lab involves a front-end and back-end server, and the front-end server doesn't support
chunked encoding. The front-end server is caching static resources. To solve the lab,
perform a request smuggling attack such that the next user's request causes their API key
to be saved in the cache. ya tengo la peticion q creo e sla vulnerale, como hago para
verificar q si exista esta vulnerabilidad
ChatGPT said:
Perfecto, ya tienes una petición candidata a ser vulnerable a HTTP request smuggling, y el
objetivo es que el backend interprete una solicitud oculta que el frontend no ve,
haciendo que la respuesta del backend (con la API key de otro usuario) sea cacheada por
el frontend.
Objetivo
Hacer que la siguiente petición de un usuario genere una respuesta con su API key, y esa
respuesta quede cacheada por el frontend.
Pasos para verificar si la vulnerabilidad existe:
1. Confirma que el frontend y backend interpretan diferente
Envía una solicitud que contenga ambas cabeceras:
http
CopyEdit
POST / HTTP/1.1
Host: [Link]
Content-Length: 4
Transfer-Encoding: chunked
GET /some-path HTTP/1.1
Foo: bar
¿Qué observar?
• Si ves una respuesta inesperada o con comportamiento anómalo (por ejemplo,
respuesta mezclada, error 4xx raro, o sin relación con la petición enviada),
probablemente existe un desincronización entre frontend y backend.
Tú puedes simular eso haciendo una nueva petición tú misma (como si fueras el siguiente
usuario), por ejemplo:
http
CopyEdit
GET /resources/js/[Link] HTTP/1.1
Host: [Link]
Si recibes en esa respuesta contenido que normalmente no está ahí (como una API
key), lograste la smuggling + cache poisoning.
POST / HTTP/1.1
Host: [Link]
Content-Length: 4
Transfer-Encoding: chunked
Connection: keep-alive
0
GET /some-path HTTP/1.1
Foo: bar
El frontend ve Content-Length: 4 y omite el cuerpo real, porque no entiende Transfer-
Encoding: chunked.
El backend, que sí entiende Transfer-Encoding, ve un cuerpo chunked (terminado con
0\r\n\r\n) y luego interpreta la línea GET /some-path HTTP/1.1 como una nueva solicitud.
Esa segunda solicitud será tratada como válida por el backend pero no la verá el
frontend.