Web Cache Deception(Engaño de caché); Explicación y PoC
En el mundo de la seguridad web, una de las técnicas más interesantes y peligrosas es la Web Cache Deception. Esta técnica permite a un atacante manipular las reglas de almacenamiento en caché de un servidor web para almacenar y servir contenido sensible o malicioso a otros usuarios. En este artículo, exploraremos cómo funciona esta técnica, sus implicaciones y cómo se puede llevar a cabo un ataque de este tipo, utilizando ejemplos prácticos y detallados.
¿Qué es la Web Cache Deception?
La Web Cache Deception es una técnica en la que un atacante engaña a un servidor de caché web para que almacene y sirva contenido que no debería estar en la caché. Esto se logra manipulando las reglas de almacenamiento en caché del servidor, que determinan qué respuestas HTTP se pueden almacenar y servir a otros usuarios.
¿Por qué es peligrosa?
- Exposición de información sensible: Un atacante puede almacenar información confidencial (como datos de usuario, credenciales o detalles de cuentas) en la caché, haciendo que esté disponible para otros usuarios.
- Inyección de contenido malicioso: El atacante puede inyectar scripts maliciosos, redirecciones o enlaces a sitios web maliciosos, afectando a todos los usuarios que accedan a la caché.
- Impacto amplificado: Un solo ataque puede afectar a múltiples usuarios, ya que la caché se comparte entre ellos.
¿Cómo Funciona?
Para entender cómo funciona la Web Cache Deception, es importante conocer cómo operan los servidores de caché web. Estos servidores almacenan copias de las respuestas HTTP para mejorar el rendimiento y reducir la carga en el servidor de origen. Sin embargo, si un atacante manipula las reglas de almacenamiento en caché, puede controlar qué contenido se almacena y se sirve a otros usuarios.
1. Reglas de Coincidencia Exacta de Caché
Las reglas de coincidencia exacta de caché determinan si una respuesta puede ser almacenada y servida a otros usuarios. Estas reglas pueden incluir:
- URL completa: Si la caché utiliza la URL completa como clave, cualquier variación en la URL resultará en una entrada de caché diferente.
- Encabezados HTTP: Algunos servidores de caché utilizan encabezados HTTP (como
User-Agent
oCookie
) para determinar si una respuesta debe ser almacenada. - Parámetros de consulta: Los parámetros en la URL (por ejemplo,
?param=value
) pueden influir en cómo se almacena una respuesta.
2. Manipulación de la URL o Encabezados HTTP
El atacante puede manipular la URL o los encabezados HTTP para crear una respuesta que coincida exactamente con las reglas de caché del servidor. Esto puede incluir:
- Inyección de parámetros adicionales en la URL: Por ejemplo, agregar
?cache=true
a la URL. - Modificación de encabezados HTTP: Cambiar encabezados como
User-Agent
oCookie
para influir en el comportamiento de la caché.
3. Inyección de Contenido Malicioso
Una vez que el atacante ha manipulado la URL o los encabezados HTTP, puede inyectar contenido malicioso en la respuesta. Esto puede incluir:
- Scripts maliciosos: Código JavaScript que roba credenciales, redirige a sitios maliciosos o realiza otras acciones dañinas.
- Redirecciones: Redirigir a los usuarios a un sitio web controlado por el atacante.
- Contenido falso: Mostrar información falsa o engañosa.
Ejemplo Práctico
Vamos a ver un ejemplo práctico de cómo se puede llevar a cabo un ataque de Web Cache Deception. En este ejemplo, manipularemos la URL para inyectar contenido malicioso en la caché del servidor.
Iniciar Sesión como Usuario
Primero, iniciamos sesión como el usuario «wiener» con la contraseña «peter».

Esto nos permitirá acceder con burp a la página de perfil y ver la información del usuario. En este caso el csrf token,

Acceder a la Página de Perfil
Una vez que hemos iniciado sesión, podemos ver la página de perfil del usuario «wiener». Aquí podemos ver su nombre de usuario y cambiar su dirección de correo electrónico.


Identificar Reglas de Caché
Ciertos archivos como robots.txt
, index.html
, y favicon.ico
son archivos comunes que se encuentran en los servidores web. A menudo se almacenan en caché debido a sus cambios poco frecuentes. Las reglas de caché apuntan a estos archivos haciendo coincidir la cadena de nombre de archivo exacta.
Para identificar si hay una regla de caché de nombre de archivo, enviamos una solicitud GET a un posible archivo y vemos si la respuesta está en caché.
La respuesta contiene el encabezado X-Cache: miss
, lo que indica que la respuesta no está en caché.

Sin embargo, al enviar la solicitud nuevamente, el encabezado cambia a X-Cache: hit
, lo que indica que la respuesta está en caché. Esto muestra que la caché tiene una regla para almacenar respuestas basadas en el nombre del archivo /robots.txt
.

Manipular la URL para Inyectar Contenido Malicioso
Para engañar a la caché, podemos manipular la URL para que apunte a un archivo que sabemos que está en caché, como robots.txt
. Sin embargo, necesitamos encontrar un delimitador como puede ser ;
o ?
que el servidor de origen interprete de manera diferente a la caché.
Al igual que la detección de la normalización por el servidor de origen, podemos elegir una solicitud con una respuesta en caché y reenviar la solicitud con una secuencia de recorrido de ruta y un directorio arbitrario al comienzo de la ruta estática.
Por ejemplo, podemos almacenar en caché /robots.txt
. Y añadirlela ruta /algo/..%2f/robots.txt
:

Como se puede ver, la respuesta aún se almacena en caché, esto puede indicar que la caché ha normalizado la ruta.
La respuesta solo se almacena en caché si la solicitud coincide con el nombre exacto del archivo solo podemos explotar una discrepancia en la que el servidor de caché resuelve segmentos de puntos codificados, pero el servidor de origen no.
Para hacerlo, podemos construir una carga útil de acuerdo con la siguiente estructura: /<dynamic-path>%2f%2e%2e%2f<static-directory-prefix>
.
Sin embargo, dado que es probable que el servidor de origen devuelva un mensaje de error en lugar de información de perfil, también deberemos hacerlo identifique un delimitador utilizado por el servidor de origen pero no por la caché. Probamos posibles delimitadores como puede ser ;
o ?
agregándolos a la carga útil después de la ruta dinámica. Vemos como el delimitador ?
no surge efecto.

Pero después de probar varios delimitadores, encontramos que el carácter ;
es el delimitador adecuado. La ruta /my-account;/%2f%2e%2e/%2frobots.txt
resulta en una respuesta diferente en el servidor de origen y el servidor de caché:
- El caché interpreta la ruta como:
/robots.txt
- El servidor de origen interpreta la ruta como:
/my-account


Robar el Token CSRF
Ahora que sabemos cómo manipular la caché, podemos robar el token CSRF del usuario administrador. Para ello, creamos un exploit que navegue al usuario víctima a una URL maliciosa que refleje la página de perfil del administrador.
- En el navegador, hacemos clic en «Ir a explotar el servidor» de PowstSwigger.
- En la sección «Cuerpo», creamos un exploit que navegue al usuario víctima a la URL maliciosa que creamos. Asegúrandonos de agregar un parámetro arbitrario como un buster de caché.

- Hacemos clic en «Entregar exploit a la víctima».
- En la pestaña «Repeater» que contiene la solicitud
/my-account
, cambiamos la ruta para reflejar la URL que entregamos a la víctima en nuestro exploit. Por ejemplo,/my-account;/%2f%2e%2e/%2frobots.txt?
. - Enviamos la solicitud. Asegurándonos de hacer esto dentro de los 30 segundos posteriores a la entrega del exploit a la víctima. De lo contrario, envíamos el exploit de nuevo con un buster de caché diferente.
Obtener el Token CSRF
Observamos que la respuesta incluye el token CSRF para el usuario administrador. Copiamos este token.

Cambiar la Dirección de Correo Electrónico del Administrador
Usamos el token CSRF del administrador para cambiar su dirección de correo electrónico. Cambiamos la dirección de correo electrónico en nuestro exploit para que no coincida con la nuestra.

Este exploit enviará automáticamente el formulario de actualización de correo electrónico al visitar.

Impacto y Consecuencias
El impacto de un ataque de Web Cache Deception puede ser devastador:
- Exposición de información sensible: Si un atacante almacena información confidencial en la caché, otros usuarios pueden acceder a ella.
- Ejecución de código malicioso: Los scripts maliciosos pueden robar credenciales, redirigir a sitios maliciosos o realizar otras acciones dañinas.
- Manipulación de datos: El atacante puede mostrar información falsa o engañosa a los usuarios.
Cómo Prevenir la Web Cache Deception
Para protegerse contra la Web Cache Deception, los desarrolladores y administradores de sistemas pueden tomar las siguientes medidas:
- Configurar correctamente las reglas de caché: Asegurarse de que solo las respuestas seguras se almacenen en la caché.
- Validar las entradas del usuario: Validar y sanitizar todas las entradas del usuario para evitar la inyección de contenido malicioso.
- Usar encabezados de seguridad: Utilizar encabezados HTTP como
Cache-Control
yPragma
para controlar el comportamiento de la caché. - Monitorear el tráfico: Monitorear el tráfico de red para detectar y bloquear intentos de manipulación de la caché.
Conclusión
La Web Cache Deception es una técnica poderosa y peligrosa que puede ser explotada por atacantes para manipular la caché de un servidor web. Al comprender cómo funciona esta técnica y sus implicaciones, los desarrolladores y administradores de sistemas pueden tomar medidas para proteger sus aplicaciones web y evitar que sean víctimas de este tipo de ataques. Con ejemplos prácticos y una comprensión clara de los mecanismos involucrados, es posible fortalecer la seguridad de las aplicaciones web y proteger a los usuarios de posibles amenazas.