¿Qué es CRLF?

Cuando un navegador envía una solicitud a un servidor web, el servidor web responde con una respuesta que contiene los encabezados de respuesta HTTP y el contenido real del sitio web, es decir, el cuerpo de la respuesta. Los encabezados HTTP y la respuesta HTML (el contenido del sitio web) están separados por una combinación específica de caracteres especiales, a saber, un retorno de carro y un avance de línea. Para abreviar, también se conocen como CRLF.

El servidor web utiliza el CRLF para entender cuándo comienza un encabezado HTTP nuevo y termina otro. El CRLF también puede indicar a una aplicación web o a un usuario que una nueva línea comienza en un archivo o en un bloque de texto. Los caracteres CRLF son un mensaje HTTP / 1.1 estándar, por lo que es utilizado por cualquier tipo de servidor web, incluidos Apache, Microsoft IIS y todos los demás.

¿Qué es la vulnerabilidad de inyección de CRLF?

En un ataque de vulnerabilidad de inyección de CRLF, el atacante inserta tanto el retorno de carro como los caracteres de alimentación de línea en la entrada del usuario para engañar al servidor, a la aplicación web o al usuario para que piense que un objeto ha terminado y otro ha comenzado. Como tal, las secuencias CRLF no son caracteres maliciosos, sin embargo, se pueden usar para la intención maliciosa, para la división de respuestas HTTP, etc.

Inyección de CRLF en aplicaciones web

En aplicaciones web, una inyección de CRLF puede tener impactos graves, dependiendo de lo que haga la aplicación con elementos individuales. Los impactos pueden ir desde la divulgación de información hasta la ejecución de código, una vulnerabilidad de seguridad de aplicaciones web de impacto directo. De hecho, un ataque de inyección de CRLF puede tener repercusiones muy graves en una aplicación web, a pesar de que nunca se incluyó en la lista de los 10 mejores de OWASP. Por ejemplo, también es posible manipular archivos de registro en un panel de administración como se explica en el siguiente ejemplo.

Un ejemplo de inyección de CRLF en un archivo de registro

Imagine un archivo de registro en un panel de administración con el patrón de flujo de salida de la ruta de acceso visitada por IP, como el siguiente:

123.123.123.123 - 08:15 - /index.php?page=home

Si un atacante puede inyectar los caracteres CRLF en la solicitud HTTP, puede cambiar el flujo de salida y falsificar las entradas de registro. Puede cambiar la respuesta de la aplicación webs a algo como lo siguiente:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Los %0d y % 0a son las formas codificadas de url de CR y LF. Por lo tanto, las entradas de registro se verían así después de que el atacante insertara esos caracteres y la aplicación los mostrara:

Ruta IP visitada

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Por lo tanto, al explotar una vulnerabilidad de inyección CRLF, el atacante puede falsificar entradas en el archivo de registro para ofuscar sus propias acciones maliciosas. El atacante está literalmente haciendo un secuestro de página y modificando la respuesta. Por ejemplo, imagine un escenario en el que el atacante tiene la contraseña de administrador y ejecuta el parámetro restrictedaction, que solo puede ser utilizado por un administrador.

El problema es que si el administrador nota que una IP desconocida usó el parámetro restrictedaction, notará que algo está mal. Sin embargo, como ahora parece que el comando fue emitido por el host local (y por lo tanto probablemente por alguien que tiene acceso al servidor, como un administrador), no parece sospechoso.

Toda la parte de la consulta que comienza con %0d % 0a será manejada por el servidor como un parámetro. Después de eso hay otro & con el parámetro acción restringida que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:

/index.php?page=home&restrictedaction=edit

División de respuesta HTTP

Descripción

Dado que el encabezado de una respuesta HTTP y su cuerpo están separados por caracteres CRLF, un atacante puede intentar inyectarlos. Una combinación de CRLFCRLF le dirá al navegador que el encabezado termina y el cuerpo comienza. Eso significa que ahora puede escribir datos dentro del cuerpo de respuesta donde se almacena el código html. Esto puede llevar a una vulnerabilidad de Scripting entre sitios.

Un ejemplo de división de respuestas HTTP que conduce a XSS

Imagine una aplicación que establece un encabezado personalizado, por ejemplo:

X-Your-Name: Bob

El valor del encabezado se establece a través de un parámetro get llamado «name». Si no hay codificación de URL y el valor se refleja directamente en el encabezado, es posible que un atacante inserte la combinación de CRLFCRLF mencionada anteriormente para decirle al navegador que comienza el cuerpo de la solicitud. De esta manera, puede insertar datos como la carga útil XSS, por ejemplo:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

Lo anterior mostrará una ventana de alerta en el contexto del dominio atacado.

Inyección de encabezado HTTP

Descripción

Al explotar una inyección CRLF, un atacante también puede insertar encabezados HTTP que podrían usarse para derrotar mecanismos de seguridad como el filtro XSS de un navegador o la política del mismo origen. Esto permite al atacante obtener información confidencial como tokens CSRF. También puede establecer cookies que podrían ser explotadas registrando a la víctima en la cuenta del atacante o explotando vulnerabilidades de scripting entre sitios (XSS) inexplotables.

Un ejemplo de inyección de encabezados HTTP para extraer datos confidenciales

Si un atacante es capaz de inyectar los encabezados HTTP que activan CORS (Intercambio de recursos de origen Cruzado), puede usar javascript para acceder a recursos 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í.

Impactos de la vulnerabilidad de inyección de CRLF

El impacto de las inyecciones de CRLF varía y también incluye todos los impactos de los scripts entre sitios para la divulgación de información. También puede desactivar ciertas restricciones de seguridad, como los filtros XSS y la Misma Política de origen en los navegadores de la víctima, dejándolos susceptibles a ataques maliciosos.

Cómo prevenir las inyecciones de encabezados CRLF / HTTP en aplicaciones web

La mejor técnica de prevención es no usar la entrada de los usuarios directamente dentro de los encabezados de respuesta. Si eso no es posible, siempre debe usar una función para codificar los caracteres especiales CRLF. Otra buena práctica recomendada de seguridad de aplicaciones web es actualizar su lenguaje de programación a una versión que no permita que CR y LF se inyecten dentro de funciones que establecen encabezados HTTP.

la Vulnerabilidad de la Clasificación y la Gravedad de la Tabla