Cloud Híbrida
Ciberseguridad & NaaS
AI & Data
IoT y Conectividad
Business Applications
Intelligent Workplace
Consultoría y Servicios Profesionales
Pequeña y Mediana Empresa
Sanidad y Social
Industria
Retail
Turismo y Ocio
Transporte y Logística
Energía y Utilities
HTTP response splitting
11 de noviembre de 2014
También conocido como CRLF Injection Attack, HTTP response splitting es la técnica en la que un atacante se vale
de la inyección de retornos de carro y de línea para alterar una respuesta HTTP y separarla en dos (de ahí su nombre). De esta forma puede incluir cualquier contenido en la segunda petición y poner en riesgo la seguridad y privacidad de los usuarios que visitan la web, así como pudiendo alterar la página. Típicamente, permite inyectar JavaScript.
Funcionamiento de un HTTP response splitting
El flujo de petición y respuesta HTTP habitual se muestra en el diagrama:
Esquema simple de petición y respuesta HTTP
El navegador inicia una petición (sea GET, POST o cualquiera de los otros verbos que usa HTTP) que se envía al servidor web. Este a su vez responde con un código de estado (2XX para éxito, 3XX para redirección, 4XX para error etc…) y el contenido de la respuesta, que habitualmente incluye el HTML de una web que será interpretada por el navegador del cliente.
Las diferentes líneas de una petición GET, por ejemplo, se separan por un retorno de carro y otro de línea (%0d y %0a). Si se añaden artificialmente en la petición con la intención de añadir nuevos campos, o incluso una segunda petición construida desde cero por el atacante, se produce el ataque. Abajo se muestra un diagrama de este proceso, de un ejemplo lanzado contra un servidor vulnerable de prueba:
Esquema de ataque HTTP response splitting
En esta petición se ha modificado un parámetro GET y en él se ha introducido un retorno de carro (%0d) y uno de línea (%0a) seguidos de las nuevas líneas de cada campo (Un "Content-Type" y un código JavaScript) separadas a su vez por otro CRLF (%0d%0a).
La petición que recibe el servidor quedaría así:
La respuesta del servidor podría ser esta:
Que es interpretada por el navegador del cliente de la siguiente forma:
Las consecuencias para el cliente pueden variar, pero podrían ser peligrosas. Al fin y al cabo, el servidor en el que el cliente confía, está pidiendo al cliente que ejecute acciones no deseadas que han sido creadas por un atacante (el cliente previamente tendría que ser inducido a pulsar en un enlace de este tipo). Las consecuencias claras son las mismas que en un Cross Site Scripting "típico" no persistente.
Faast incluye un plugin que evalúa, comprueba y alerta sobre la presencia de este tipo de vulnerabilidad.
Funcionamiento de un HTTP response splitting
El flujo de petición y respuesta HTTP habitual se muestra en el diagrama:
Esquema simple de petición y respuesta HTTP
El navegador inicia una petición (sea GET, POST o cualquiera de los otros verbos que usa HTTP) que se envía al servidor web. Este a su vez responde con un código de estado (2XX para éxito, 3XX para redirección, 4XX para error etc…) y el contenido de la respuesta, que habitualmente incluye el HTML de una web que será interpretada por el navegador del cliente.
Las diferentes líneas de una petición GET, por ejemplo, se separan por un retorno de carro y otro de línea (%0d y %0a). Si se añaden artificialmente en la petición con la intención de añadir nuevos campos, o incluso una segunda petición construida desde cero por el atacante, se produce el ataque. Abajo se muestra un diagrama de este proceso, de un ejemplo lanzado contra un servidor vulnerable de prueba:
Esquema de ataque HTTP response splitting
En esta petición se ha modificado un parámetro GET y en él se ha introducido un retorno de carro (%0d) y uno de línea (%0a) seguidos de las nuevas líneas de cada campo (Un "Content-Type" y un código JavaScript) separadas a su vez por otro CRLF (%0d%0a).
La petición que recibe el servidor quedaría así:
La respuesta del servidor podría ser esta:
Que es interpretada por el navegador del cliente de la siguiente forma:
Las consecuencias para el cliente pueden variar, pero podrían ser peligrosas. Al fin y al cabo, el servidor en el que el cliente confía, está pidiendo al cliente que ejecute acciones no deseadas que han sido creadas por un atacante (el cliente previamente tendría que ser inducido a pulsar en un enlace de este tipo). Las consecuencias claras son las mismas que en un Cross Site Scripting "típico" no persistente.
Faast incluye un plugin que evalúa, comprueba y alerta sobre la presencia de este tipo de vulnerabilidad.
Juan Luis Sanz
juanluis.sanz@11paths.com
