Inyección CRLF.

La inyección CRLF abusa del significado especial de la secuencia CR (0x0D) y LF (0x0A) que termina líneas en muchos protocolos textuales. Cuando una aplicación refleja entrada del usuario sin validar en cabeceras HTTP, registros, comandos SMTP o consultas LDAP, el atacante puede inyectar un par CRLF y contenido adicional para forjar cabeceras, dividir respuestas, ocultar entradas en logs o introducir comandos. La debilidad está catalogada como CWE-93 (neutralización incorrecta de secuencias CRLF); su variante específica de cabeceras HTTP es CWE-113, que cubre la división de peticiones/respuestas HTTP.

En entornos web, la forma más dañina es la división de respuestas HTTP, descrita por primera vez por Amit Klein, de Sanctum, en un artículo de 2004. Como el CRLF inyectado cierra el bloque de cabeceras, el atacante puede añadir una segunda respuesta totalmente controlada por él —envenenando cachés compartidas, fijando cookies arbitrarias o inyectando XSS en un cuerpo que el navegador considera de confianza—. El fallo reaparece en bibliotecas estándar: CVE-2019-9740 permitía que secuencias CRLF en una URL pasada a urllib.request.urlopen de Python inyectaran cabeceras HTTP (e incluso comandos Redis vía la cadena de consulta); se corrigió en Python 2.7.17 y 3.5.10/3.6.10/3.7.4. Las defensas incluyen rechazar o codificar en porcentaje los CR/LF en toda entrada destinada a cabeceras, usar APIs de alto nivel que rechacen caracteres de control en los valores de cabecera, y codificadores de logs estrictos y estructurados en lugar de la concatenación de cadenas en bruto.

flowchart TD
  A[Entrada de usuario<br/>name=foo%0d%0aSet-Cookie: admin=true] --> B{¿Validar / quitar CR LF?}
  B -->|No| C[Entrada escrita en bruto en la cabecera]
  C --> D[El CRLF termina la cabecera actual]
  D --> E[Cabecera o cuerpo controlado por el atacante]
  E --> F[Envenenamiento de caché / inyección de cookie / XSS]
  B -->|Sí, rechazar CR LF| G[Respuesta segura]