Ataque engañar al cache web

Alguna vez paso por tu cabeza enlaces como https://www.paypal.com/myaccount/home/stylesheet.css o https://www.paypal.com/myaccount/settings/notifications/logo.png podria exponer su datos confidenciales, e incluso permitir que los atacantes tomen el control de su cuenta? El engaño de cache web es un nuevo vector de ataque que pone en riesgo diversas tecnologias y frameworks.

Algunas palabras sobre almacenamiento en cache y reacciones

1.- los sitios web a menudo tienden a utilizar la funcionalidad de cache web (por ejemplo, a través de un CDN, un load balancer o simplemente un proxy inverso). El propósito es simple: almacenar archivos que a menudo se recuperan, para reducir la latencia del servidor web. Veamos un ejemplo de cache web. 

El sitio http://ejemplo.com esta configurado para pasar por un proxy inverso. Una pagina dinámica que se almacena en el servidor y devuelve contenido personal de los usuarios, como http://ejemplo.com/incio.php, tendrá que crearla dinamicamente por usuario, ya que los datos son diferentes para cada usuario. Este tipo de datos, o al menos sus partes personalizadas, no se almacenan en cache.

Lo que es mas razonable y común de la memoria cache son los archivos públicos estáticos: hojas de estilos (css), scripts (js), archivos de texto (txt), imágenes (png, bmp, gif),etc. Esto tiene sentido por que estos archivos generalmente no contienen información sensible.

Ademas, como se puede encontrar en varios artículos de mejores practicas sobre la configuración de cache web, se recomienda almacenar en cache todos los archivos estáticos que se pretende que sean públicos y descartar sus encabezados de cache HTTP.

2.- ¿Que sucede al acceder a una URL como http://ejemplo.com/inicio.php/inexistente.css? el navegador generara una solicitud GET a esa URL. Lo interesante es la reacción del servidor ¿como interpreta la URL de solicitud? Dependiendo de la tecnología y configuración (La estructura de la URL puede necesitar ser construida ligeramente diferente para versiones diferentes de servidores), el servidor devuelve el contenido de http://ejemplo.com/inicio.php. Y si, la URL sigue siendo http://ejemplo.com/inicio.php/inexistente.css. Los encabezados HTTP serán los mismos que para acceder a http://ejemplo.com/inicio.php directamente: los mismos encabezados de almacenamiento en cache y el mismo tipo de contenido (text/html, en este caso).

Ahora vamos con la introducción

¿que sucede si accedemos a http://ejemplo.com/inicio.php/inexistente.css, mientras que la memoria cache web para archivos estáticos se configura en el servidor proxy, sin tener en cuenta los encabezados de almacenamiento en cache para este tipo de archivos? analicemos este proceso:

1.- El navegador solicita http://ejemplo.com/inicio.php/inexistente.css.
2.- El servidor devuelve el contenido de http://ejemplo.com/inicio.php , muy probablemente con los encabezados de almacenamiento en caché HTTP que indican que no se debe almacenar en caché esta página.
3.- La respuesta pasa por el proxy.
4.- El proxy identifica que el archivo tiene una extensión css.

5.- Debajo del directorio de caché, el proxy crea un directorio llamado inicio.php y almacena en caché el archivo impostor "CSS" (inexistente.css) dentro.

OH

Aprovechándolo

Un atacante que atrae a un usuario que haya iniciado sesión para acceder a http://www.example.com/home.php/logo.png hará que esta página, que contiene el contenido personal del usuario, se almacene en la memoria caché y, por lo tanto, sea accesible públicamente. Podría empeorar si el cuerpo de la respuesta contiene (por alguna razón) el identificador de sesión, las respuestas de seguridad o los tokens CSRF. Todo lo que el atacante tiene que hacer ahora es acceder a esta página por su cuenta y exponer estos datos.

Nota: Por lo general, los sitios web no requieren autenticación para acceder a sus archivos públicos estáticos. Por lo tanto, los archivos almacenados en caché son de acceso público, no se requiere autenticación.


Condiciones

Entonces, básicamente, se requieren dos condiciones para que exista esta vulnerabilidad:
1.- La funcionalidad de caché web está configurada para que la aplicación web guarde en caché los archivos por sus extensiones, sin tener en cuenta ningún encabezado de caché.

2.- Al acceder a una página como http://www.ejemplo.com/inicio.php/inexistente.css , el servidor web devolverá el contenido de "inicio.php" para esa URL.

Mitigacion

1.- Configure el mecanismo de caché para almacenar en caché los archivos solo si sus encabezados de caché de HTTP lo permiten. Eso resolverá la causa raíz de este problema.
2.- Si el componente de caché proporciona la opción, configúrelo para almacenar en caché los archivos por su tipo de contenido.

3.- Configure el servidor web para que, en páginas como http://www.ejemplo.com/inicio.php/inexistente.css , el servidor web no devuelva el contenido de "inicio.php" con esta URL. En cambio, por ejemplo, el servidor debe responder con una respuesta 404 o 302.

prueba de concepto

Secuestro de usuario a través del engaño de caché web

Encontré esta vulnerabilidad en aplicaciones adicionales, que desafortunadamente no se pueden divulgar al público por diferentes razones (fastidio, tenía algunos buenos videos para eso). En estas aplicaciones, era posible tomar el control completo sobre los usuarios de la aplicación. Esto fue posible porque la ID de la sesión o las respuestas de seguridad para recuperar la contraseña de un usuario se incluyeron en el código HTML de las páginas vulnerables. 

Herramientas:

https://github.com/PortSwigger/web-cache-deception-scanner