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.
