CRLF es el acrónimo utilizado para referirse a la Alimentación de línea de Retorno de carro (\r) (\n). Como se puede observar en los símbolos entre corchetes, » Retorno de carro «se refiere al final de una línea, y» Avance de línea » se refiere a la nueva línea. Por lo tanto, tanto CR como LF se utilizan para denotar el punto final de una recta. Cuando un usuario solicita contenido en un sitio web, el servidor devuelve el contenido del sitio web junto con los encabezados HTTP. Los encabezados y el contenido están separados por una combinación definida de CR y LF. Es debido a CRLF que un servidor sabe dónde comienza o termina un nuevo encabezado. Una vulnerabilidad de Inyección de Alimentación de Línea de Retorno de Carro (CRLF) es un tipo de Inyección en el lado del servidor que ocurre cuando un atacante inserta los caracteres CRLF en un campo de entrada para engañar al servidor haciéndole pensar que un objeto ha terminado y ha comenzado uno nuevo. Esto sucede cuando la aplicación web no desinfecta la entrada del usuario para los caracteres CRLF. Tiene una clasificación de gravedad media (P3 de acuerdo con el VRT de Bugcrowd).
El ataque de inyección CRLF tiene dos casos de uso más importantes:
- División de registros: El atacante inserta un carácter de fin de línea y una línea adicional para falsificar las entradas del archivo de registro con el fin de engañar a los administradores del sistema ocultando otros ataques.División de respuesta HTTP: La inyección CRLF se usa para agregar encabezados HTTP a la respuesta HTTP y, por ejemplo, realizar un ataque XSS que conduce a la divulgación de información.
Ejemplo:
Una simple solicitud GET se puede crear de la siguiente manera:
GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1
Nota: %0d y %0a son formas codificadas de \r y \n respectivamente. Si la aplicación web es vulnerable, un atacante podrá establecer una cookie en el sitio web.
Impactos de la inyección de CRLF
La inyección de CRLF permite al atacante configurar cookies falsas, robar tokens de CSRF, divulgar información del usuario inyectando un script (XSS) y realizar una variedad de otros ataques. También permite a los atacantes desactivar & omitir medidas de seguridad como filtros XSS & Política del mismo origen (SOP), haciéndolos susceptibles a los siguientes ataques:
1. XSS o Cross Site Scripting
XSS o Cross Site Scripting es una vulnerabilidad de seguridad que permite a un atacante inyectar código JavaScript malicioso en la aplicación web. Las siguientes solicitudes GET se crean en una inyección CRLF de cadena de intentos con XSS.
Activando una alerta que contiene información confidencial del usuario
www.target.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
Desactivando la protección XSS
www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
2. La división de respuesta HTTP de Inyección de cookies permite a un atacante establecer cookies maliciosas en el navegador de la víctima. En la mayoría de los casos, la siguiente solicitud GET dará lugar a una redirección 307, y por lo tanto la víctima será redirigida a target.com & la URL no contendrá el parámetro Set-Cookie. Sin embargo, en segundo plano, se configurará la cookie.
www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet
3. Ataques de phishing Un atacante puede establecer el encabezado de ubicación que redirigiría a la víctima al sitio web maligno. Este sitio web se puede desarrollar para parecerse al sitio web de destino y cuando la víctima ingrese sus credenciales, se enviarán al atacante. El encabezado de ubicación se puede establecer como:
GET /%0d%0aLocation:%20https://evil.com HTTP/1.1
4. Fijación de sesión
Similar al ataque de inyección de cookies, aquí el atacante establece el id de sesión de un usuario en un valor particular. Este enlace se envía a la víctima y, cuando la víctima inicia sesión con esta sesión, el atacante también puede iniciar sesión con el mismo id de sesión.
www.target.com/%0d%0aSet-Cookie:session_id=942....
5. Inyección de encabezado HTTP
Un atacante puede aprovechar la inyección CRLF para inyectar encabezados HTTP en una aplicación con el fin de derrotar mecanismos de seguridad como los filtros XSS o la política del mismo origen.
www.target.com/%0d%0aHackersHeader:NewHeader
Se pueden inyectar encabezados de activación CORS (Intercambio de recursos de origen cruzado) & el atacante puede usar JavaScript para acceder a recursos confidenciales que de otro modo están protegidos por SOP (Directiva del mismo origen) que impide que los sitios de orígenes diferentes accedan entre sí.
6. El envenenamiento de caché web es una técnica debido a la cual un atacante puede servir contenido envenenado manipulando una caché web. Para explotar con éxito este problema, un atacante tendría que envenenar el proxy de almacenamiento en caché del sitio web vulnerable, los sindicadores, las redes de entrega de contenido (CDN) u otros mecanismos de almacenamiento en caché entre el cliente y el servidor. Después de un envenenamiento exitoso de la caché web, la víctima no tendrá idea del contenido malicioso que la caché le está sirviendo. El siguiente es un ejemplo de cómo un atacante podría explotar una inyección de encabezado de host (usando CRLF) envenenando una caché web.
Para la siguiente Solicitud:
$ telnet www.target.com 80Trying x.x.x.x...Connected to www.target.com.Escape character is '^]'.GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1 //or HostHost: target.com
No sería la siguiente respuesta:
HTTP/1.1 200 OK
<title>Example</title> <scriptsrc="http://hacker.com/script.js">
Varios Casos de Uso:
1. Inyectar un encabezado de respuesta HTTP falso:
Content-Length: 10
Ahora, el navegador web solo analizará los siguientes 10 bytes.
2. Inyectar un encabezado de respuesta HTTP falso:
Content-Length: 0
Esto se trata como una respuesta terminada & los navegadores web comienzan a analizar una nueva respuesta.
Mitigaciones:
Un desarrollador debe tener en cuenta lo siguiente para evitar la inyección de CRLF:
- Desinfección de la entrada del usuario.
- Codifique CR & caracteres LF (\r, \n) para que, incluso cuando se suministran, no sean reconocidos por el servidor.
- Valide la entrada del usuario antes de que llegue a los encabezados de respuesta (por ejemplo, utilizando métodos como StringEscapeUtils).escapeJava ()).
- Un encabezado innecesario debe desactivarse.La siguiente tabla enfatiza la gravedad de la inyección de CRLF de acuerdo con varios estándares de la industria:
| Classification | ID / Severity |
|---|---|
| OWASP 2017 | A1 |
| CWE | 93 |
| CVSS:3.0 | CVSS:3.0: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H |
| Bugcrowd VRT | P3 |