CRLF Injection / HTTP Response Splitting

La CRLF Injection ocurre cuando una entrada del usuario acaba dentro de una cabecera HTTP (o de un log, o de una redirección) sin sanear los caracteres de fin de línea \r\n (CRLF, %0d%0a). Como esos dos bytes separan cabeceras entre sí y del cuerpo, inyectarlos permite añadir cabeceras propias e incluso partir la respuesta en dos (HTTP Response Splitting).

El caso típico es un valor reflejado en Location, Set-Cookie o una cabecera personalizada:

GET /redir?url=/inicio%0d%0aSet-Cookie:%20sesion=atacante HTTP/1.1
Host: victima

Si el servidor emite Location: /inicio con nuestro valor, el %0d%0a cierra la cabecera y añade un Set-Cookie que nosotros controlamos (fijación de sesión). Llevándolo más lejos, un doble CRLF cierra las cabeceras e inyecta un cuerpo entero:

/redir?url=x%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<script>alert(1)</script>

De ahí sale un XSS reflejado por la respuesta partida, una redirección abierta (open redirect), o la inyección de líneas falsas en los logs (envenenamiento de logs) para confundir el análisis.

Cómo detectarlo. La firma es una petición cuyos parámetros contienen %0d%0a (o \r\n sin codificar) justo antes de nombres de cabecera (Set-Cookie, Location, Content-Length), y una respuesta con cabeceras duplicadas o un segundo bloque de estado HTTP/1.1 200. En los logs del proxy, líneas de petición partidas o cabeceras inesperadas en respuestas de una ruta que solo debía redirigir.

Defensa. No reflejar entrada del usuario en cabeceras; si es inevitable, eliminar o codificar \r y \n antes de construirlas. Los frameworks modernos rechazan CRLF en las APIs de cabecera, así que el fallo casi siempre está en código que concatena cabeceras a mano. Es primo del Host header injection y suele preceder a un envenenamiento de caché.