
Descripción
This lab is vulnerable to web cache poisoning because it excludes a certain parameter from the cache key. There is also inconsistent parameter parsing between the cache and the back-end. A user regularly visits this site’s home page using Chrome.
To solve the lab, use the parameter cloaking technique to poison the cache with a response that executes alert(1)
in the victim’s browser.
Parameter cloaking writeup
Dividiremos el laboratorio en varios pasos:
Determinar que el laboratorio usa caché
Esto lo podremos averiguar viendo los siguientes tres atributos en una respuesta:

Si se encuentran podemos suponer que un ataque de envenenamiento de caché es posible.
Localizar un cache buster
Un cache buster nos permite refrescar la caché más rápido y evitar interferir con los usuarios que navegan. En este caso se puede encontrar añadiendo una cadena de caracteres aleatoria detrás de un ‘?’ en la URL, por ejemplo: ‘/?test’. Cuando queramos refrescar la caché cambiaremos la cadena de caracteres.

En este caso el cache buster también edita el link ‘canonical’, permitiendo inyectar JavaScript en la página, pero no en la de la victima debido a que el buster forma parte de la clave de caché, por lo que el servidor sólo nos entregará esta versión a nosotros. Tendríamos que enviarle la URL a la víctima (realizando un XSS reflejado entonces), y no un envenenamiento de caché.
Encontrar el parámetro que puede editar la página de otros usuarios y no forma parte de los key params
Daremos Click derecho en la parte de ‘Request’ -> Extensions -> Param Miner -> Guess query params. Al finalizar el escaneo nos mostrará el parámetro ‘utm_content’, igual que en el laboratorio anterior (Web cache poisoning via an unkeyed query parameter):

En este caso, poner directamente en el valor del parámetro ‘utm_content’ la etiqueta <sccript> no dará resultado, dado que se codificará automáticamente. Buscaremos dónde poder usar este parámetro. Entre los archivos de JavaScript se encuentra el siguiente:

Que toma de la URL el valor del nombre de la función ‘setCountryCookie’. Si cambiamos su nombre por una función, JavaScript la llamará para intentar obtener el nombre de la función. Para ello tenemos que usar una técnica de ‘parameter pollution’, metiendo en ‘utm_content’ un nuevo parámetro para ‘callback’, creando así un caché para todos los usuarios.:
GET /js/geolocate.js?callback=setCountryCookie&utm_content=test;callback=alert(1)
En este caso, la contaminación del parámetro se puede realizar con ‘;’, esto porque probablemente el frontend y el backend estén programados en lenguajes distintos. El frontend no interpreta el ‘;’ como un separador de parámetros, pero el backend sí. Como para el frontend ‘;callback=alert(1)’ es parte del parámetro que no afecta a la creación de caché único lo usa para obtener el general. El backend, sin embargo, interpreta el ‘;’ como un serparador y sobreescribe el valor del nombre de la función en JavaScript.
Completando así el laboratorio:
