Introducción al Request Smuggling CL.TE
CL.TE significa Content-Length/Transfer-Encoding. El nombre viene de los dos headers involucrados. En una técnica CL.TE, el atacante explota discrepancias entre cómo los diferentes servidores priorizan estos headers. Por ejemplo:
- El proxy usa el header Content-Length para determinar el final de una petición.
- El servidor backend usa el header Transfer-Encoding.
Debido a esta discrepancia, es posible craftear peticiones ambiguas que son interpretadas de forma diferente por cada servidor. Por ejemplo, imagina mandar una petición con ambos headers. El servidor frontend puede usar CL y pensar que la petición termina en cierto sitio. En contraste, el servidor backend, confiando en el header TE, puede interpretar la petición de forma diferente, implicando comportamiento inesperado.
Explotar CL.TE para Request Smuggling
Para explotar la técnica CL.TE, un atacante craftea una petición que incluye ambos headers, asegurándose que el front y el back interpretan las fronteras de la petición de forma diferente. Por ejemplo, el atacante manda:
POST /search HTTP/1.1 Host: example.com Content-Length: 130 Transfer-Encoding: chunked 0 POST /update HTTP/1.1 Host: example.com Content-Length: 13 Content-Type: application/x-www-form-urlencoded isadmin=true
Aquí, el frontend ve el Content-Length de 130 bytes y cree que la petición termina después de isadmin=true. Sin embargo, el backend ve el Transfer-Encoding: chunked e interpreta el 0 como final del chunk, haciendo que la segunda petición empiece en un nuevo chunk. Esto puede llevar a que el backend trate el POST /update HTTP/1.1 como una nueva petición separada, potencialmente dándole al atacante acceso no autorizado.
Content-Length Incorrecto
Al crear un payload de request smuggling, si el Content-Length no es igual a la longitud real del contenido, pueden surgir varios problemas. Primero, el servidor puede procesar sólo la porción de la petición que coincide con el CL. Esto podría resultar en una parte contrabandeada y parte ignorada o no procesada. Por ejemplo, en la captura de abajo, el tamaño original del body es 24 bytes.
Para verificar que el CL es válido, podemos comprobar el directorio /submissions para verificar si el body entero fue guardado en el archivo .txt.
Como el tamaño del body username=test&query=test es 24 bytes, mandar un CL con un tamaño inferior a este le dirá al servidor que interprete el body diferente. Por ejemplo, si el CL se pone menor, el backend sólo leerá parte de la petición basado en el CL especificado. Por ejemplo, configurar CL a 10 bytes significa que el servidor sólo considerará los primeros 10 bytes del body.
La misma petición con Content-Length: 10 se ve así en el archivo de texto.
