Comprensión de la inyección CRLF: vulnerabilidad y mitigación de una aplicación web

Inicio » Ciberseguridad » Seguridad de aplicaciones » Comprensión de la inyección CRLF: una vulnerabilidad y mitigación de una aplicación web

La inyección CRLF (Carriage Return Line Feed) es una vulnerabilidad de una aplicación web que se produce cuando un atacante puede inyectar caracteres CRLF maliciosos en una respuesta HTTP. Esta vulnerabilidad puede provocar varios problemas de seguridad, como inyección de encabezados HTTP, división de respuestas HTTP, fijación de sesiones, secuencias de comandos entre sitios (XSS) y envenenamiento de caché.

Para comprender la inyección CRLF, analicemos el término:

Retorno de carro (CR):Es un carácter de control (código ASCII 13) que indica al cursor que regrese al principio de la línea actual.

Avance de línea (LF):Es un carácter de control (código ASCII 10) que indica al cursor que pase a la siguiente línea.

En el contexto de HTTP, CRLF se refiere a la secuencia de caracteres CR y LF (“\r\n”). Estos caracteres se utilizan para separar líneas en el protocolo HTTP.

La vulnerabilidad de inyección CRLF surge cuando los datos (entradas) controlados por el usuario no se desinfectan o validan adecuadamente antes de usarse para construir una respuesta HTTP. Los atacantes aprovechan esta vulnerabilidad inyectando caracteres CRLF en la entrada del usuario con el objetivo de manipular la respuesta HTTP.

La inyección CRLF se puede utilizar como parte de una cadena de vulnerabilidades para explotar diversos problemas de seguridad. A continuación se muestran algunas vulnerabilidades comunes de la cadena que se pueden aprovechar junto con la inyección CRLF:

La inyección CRLF se puede combinar con otras vulnerabilidades, como una validación de entrada inadecuada o una concatenación insegura de la entrada del usuario, para realizar ataques de división de respuesta HTTP. Al inyectar caracteres CRLF, un atacante puede manipular los encabezados de respuesta y potencialmente dividir la respuesta en varias partes, lo que genera diversos problemas de seguridad como envenenamiento de caché, corrección de sesión o secuencias de comandos entre sitios (XSS).

Ejemplo:

Consideremos un ejemplo diferente en el que el segmento de código lee la dirección de correo electrónico de un usuario de una solicitud HTTP y la establece como encabezado de cookie en una respuesta HTTP:

En este ejemplo, la aplicación toma la dirección de correo electrónico enviada en la solicitud y la configura como una cookie denominada "user_email" en la respuesta HTTP.

Supongamos que la dirección de correo electrónico “[email protected]” se envía en la solicitud. La respuesta HTTP que incluye esta cookie podría verse así:

Esta respuesta mantiene su forma prevista porque la entrada (“[email protected]”) es una dirección de correo electrónico válida sin caracteres dañinos.

Ahora, consideremos qué sucede si un atacante envía una dirección de correo electrónico maliciosa que contiene caracteres CRLF:

El valor del parámetro "correo electrónico" es "john.doe%40example.com%0d%0aSet-Cookie%3A+admin%3Dtrue%0d%0a". Cuando la aplicación procesa esta entrada y establece la cookie, la respuesta HTTP podría manipularse de la siguiente manera

En este caso, el atacante inyectó caracteres CRLF (“%0d%0a”) en el parámetro de correo electrónico, lo que llevó a la inserción de un encabezado adicional “Set-Cookie” en la respuesta. El atacante efectivamente ha configurado otra cookie llamada "admin" con el valor "verdadero". Esto podría usarse para escalar privilegios u otros ataques relacionados con la seguridad.

La inyección CRLF se puede utilizar como trampolín para ataques de secuencias de comandos entre sitios. Al inyectar caracteres CRLF para manipular la respuesta, un atacante puede introducir scripts maliciosos que pueden ejecutarse en el contexto de otros usuarios, lo que lleva al secuestro de sesiones, el robo de datos u otras formas de acceso no autorizado.

Ejemplo:

Dejemos crear una carga útil para escalar CRLF a Cross Site Scripting (XSS):

Mientras realizaba una VAPT (Evaluación de vulnerabilidades y pruebas de penetración) en una aplicación web, descubrí una posible vulnerabilidad CRLF (Carriage Return Line Feed). Encuentre la explicación para la detección y explotación de la vulnerabilidad CRLF con prueba de concepto:

Al agregar comentarios, todos los encabezados y contenidos innecesarios se incluyen en comentarios. El comentario HTML se utiliza porque la respuesta tiene un encabezado Content-Type:text/html.

Carga útil: (XSS vía CRLF)

Imagen 1: Solicitud y respuesta de URL maliciosa

Imagen 2: Al abrir la URL maliciosa en el navegador del usuario, JavaScript se ejecuta correctamente.

El flujo básico para verificar la inyección CRLF en cualquier aplicación web es el siguiente:

El proceso anterior se puede automatizar utilizando la plantilla de núcleos que se describe a continuación.

Automatización: Plantilla de núcleos para validar comprobaciones CRLF básicas:

%0d corresponde a la representación hexadecimal ASCII del carácter de retorno de carro (CR) (decimal 13).

%0a corresponde a la representación hexadecimal ASCII del carácter de avance de línea (LF) (decimal 10).

En la codificación de URL, los caracteres que no son seguros para su uso en una URL se reemplazan con un "%" seguido de su representación hexadecimal ASCII. Esto se usa comúnmente al enviar datos en URL o como parte de parámetros de consulta.

\r representa el carácter de retorno de carro (CR).

\n representa el carácter de avance de línea (LF).

En muchos lenguajes de programación, las secuencias de escape se utilizan para representar caracteres especiales que no se pueden escribir o imprimir directamente con facilidad. “\r” y “\n” son secuencias de escape utilizadas para representar los caracteres CR y LF, respectivamente. Estas secuencias de escape se usan comúnmente en cadenas literales dentro del código para especificar saltos de línea u otros caracteres de control.

Cargas útiles de omisión de filtro:

%E5%98%8A: Esta es una representación de un carácter usando codificación URL. Corresponde a la codificación UTF-8 del carácter 嘊. En UTF-8, 嘊 está representado por los bytes 0xE5 0x98 0x8A.

%0A: Esta es la representación del carácter de avance de línea (LF) en la codificación de URL. En ASCII, LF tiene el valor hexadecimal 0x0A, que corresponde al decimal 10. Representa una nueva línea o un salto de línea en el texto.

\u560a: Esta es la representación del carácter 嘊 usando una secuencia de escape Unicode en lenguajes de programación. El punto de código Unicode de 嘊 es U+560A, y la secuencia de escape \u se utiliza para representar caracteres Unicode en una cadena literal.

%E5%98%8D: Esta es otra representación de un carácter que utiliza codificación URL. Corresponde a la codificación UTF-8 del carácter 嘍. En UTF-8, 嘍 está representado por los bytes 0xE5 0x98 0x8D.

%0D: Esta es la representación del carácter de retorno de carro (CR) en la codificación URL. En ASCII, CR tiene el valor hexadecimal 0x0D, que corresponde al decimal 13. Representa un retorno de carro o el cursor que se mueve al principio de la línea.

\u560d: Esta es la representación del carácter 嘍 usando una secuencia de escape Unicode en lenguajes de programación. El punto de código Unicode de 嘍 es U+560D.

Creemos una carga útil para escalar CRLF a redirección abierta:

Para evitar vulnerabilidades de inyección CRLF, es fundamental seguir prácticas de codificación segura, como:

https://owasp.org/www-community/vulnerabilities/CRLF_Injection

https://book.hacktricks.xyz/petesting-web/crlf-0d-0a

La publicación Comprensión de la inyección CRLF: una vulnerabilidad y mitigación de una aplicación web apareció por primera vez en WeSecureApp :: Simplificando la seguridad empresarial.

*** Este es un blog sindicado de Security Bloggers Network de WeSecureApp :: Simplificando la seguridad empresarial escrito por Sekhar Poola. Lea la publicación original en: https://wesecureapp.com/blog/understanding-crlf-injection-a-web-application-vulnerability-and-mitigation/