CRLF injection

CRLF son los caracteres de retorno de carro y nueva línea (\r\n, en URL %0d%0a) que separan cabeceras y líneas en protocolos de texto como HTTP y SMTP. Si una app refleja entrada del usuario en una cabecera de respuesta, en un correo o en un log sin filtrar esos caracteres, el atacante inyecta nuevas líneas y con ellas cabeceras, cuerpo o entradas falsas.

Modelo de amenaza

HTTP response splitting: inyectar cabeceras (Set-Cookie para session fixation, Location para redirigir) o un segundo cuerpo de respuesta.
XSS por inyección de cuerpo en la respuesta.
Web cache poisoning (envenenar la respuesta cacheada).
Email header injection: en formularios de contacto, inyectar Bcc:/To: para enviar spam o robar.
Log injection/forging: falsear o romper entradas de log (ocultar rastro, inyectar datos engañosos, o incluso payloads hacia sistemas que procesan los logs).

Anatomía

Entra donde la entrada del usuario acaba en una cabecera o en una línea de un protocolo de texto: parámetros reflejados en Location (redirecciones basadas en parámetro), Set-Cookie, cabeceras personalizadas, cabeceras de correo, o ficheros de log. La clave es que %0d%0a no se filtre antes de escribir la cabecera/línea.

Red Team

# Inyección de cabecera / cookie en un redirect basado en parámetro
/redirect?url=https://x%0d%0aSet-Cookie:%20sid=attacker%3b%20HttpOnly

# Response splitting -> inyectar cuerpo / XSS (doble CRLF cierra cabeceras)
?q=foo%0d%0aContent-Length:%200%0d%0a%0d%0a<html><svg onload=alert(1)>

# Redirección forzada
?lang=en%0d%0aLocation:%20https://evil.tld

# Email header injection (formulario de contacto)
nombre=pepe%0d%0aBcc:%20victima@tld.com

# Log forging (falsear una línea de log)
User-Agent: normal%0d%0a2026-01-01 00:00:00 [INFO] usuario admin autenticado desde 10.0.0.1

Prueba también variantes de codificación: %0d%0a, %0D%0A, %E5%98%8A%E5%98%8D (unicode que algunos stacks normalizan a CRLF), y solo %0a/%0d.

Herramientas

Burp Suite (inyectar %0d%0a en parámetros/cabeceras), fuzzing con listas de CRLF de PayloadsAllTheThings.

Blue Team

Detección

Entrada con %0d%0a/\r\n reflejada en cabeceras; cabeceras duplicadas o inesperadas en respuestas; Set-Cookie/Location con valores controlados por parámetros; líneas de log con estructura rota.

Telemetría y fuentes

WAF con inspección de cabeceras, logs del servidor/aplicación, y validación de integridad de logs.

Hardening

Eliminar/escapar CR y LF de cualquier entrada que vaya a una cabecera, un correo o un log.
No poner entrada del usuario en cabeceras; usar las APIs del framework que ya rechazan CRLF en cabeceras (la mayoría de runtimes modernos lo hacen).
Para correo, usar librerías que separan cabeceras de cuerpo y sanean los campos.
Validar/normalizar y codificar antes de registrar en logs (evitar log injection).

Respuesta

Corregir la construcción de la cabecera/correo/log, purgar cachés envenenadas, e invalidar cookies inyectadas (fixation).

CVEs y casos reales

HTTP response splitting / CRLF afectó a numerosos proxies, frameworks y aplicaciones; hoy muchos runtimes bloquean CRLF en cabeceras, pero sigue apareciendo en:
- Código que construye cabeceras a mano (redirecciones, cookies por parámetro).
- Formularios de correo sin saneo (email header injection).
- Sistemas de logging (log forging), a veces como paso previo a otros ataques.

CVEs/incidentes en NVD (https://nvd.nist.gov/vuln/search) y GitHub Advisories (https://github.com/advisories).

Checklist de prueba

Inyección %0d%0a en parámetros que van a Location/Set-Cookie.
Response splitting (cabecera adicional / cuerpo / XSS).
Email header injection en formularios de contacto (Bcc:).
Log injection si la entrada acaba en logs.
Probadas variantes de codificación del CRLF.