Injection dans la clé de cache

Cache key injection

Injection dans la clé de cache

Nous devons combiner plusieurs failles (dont cache key injection) pour faire exécuter alert(1) dans le navigateur de la victime. Le lab impose l’usage de l’en-tête Pragma: x-get-cache-key.

Reconnaissance

1) Comportement du login

  • Nous avons un panneau de connexion.

  • Après login, nous sommes redirigés vers /login/?lang=en.

  • Une cookie de session est ensuite définie.

2) Réflexion du paramètre lang

  • Notre entrée apparaît dans la réponse via lang :

    • Exemple : /login/?lang=HELLLOOOO

Si nous mettons des balises HTML (ex: <h1>), ça ne s’exécute pas : il y a de l’HTML encoding.

Point d’entrée exploitable

Fichier JS cacheable : localize.js

Nous remarquons un script en arrière-plan :

  • /js/localize.js?lang=en&cors=0

  • Réponse observée :

    • document.cookie = 'lang=en';

Si nous changeons lang, la valeur est reflétée :

  • /js/localize.js?lang=hello&cors=0 → le hello apparaît dans la réponse.

Observation de la clé de cache

Nous ajoutons :

Et nous récupérons la clé :

  • X-Cache-Key: /js/localize.js?lang=en&cors=0$$

Nous constatons que cors influence la clé, et qu’en jouant sur Origin + cors, nous pouvons faire varier ce qui entre dans la cache.

Injection d’en-têtes via retour chariot

Nous utilisons l’injection CRLF :

  • %0d%0a

Nous envoyons :

  • Origin: hello%0d%0aSet-Cookie:%20csrfKey=a

Résultat : la cookie est bien interprétée côté réponse.

Injection de JavaScript en manipulant Content-Length

Nous tentons ensuite d’injecter du contenu dans la réponse avec :

  • Origin: x%0d%0aContent-Length:%208%0d%0a%0d%0aalert(1)$$$$

Dans la réponse, nous retrouvons alert(1).

Construire la réponse cacheable ciblée

Pour que le serveur stocke cette version (avec alert(1)), la cache key doit correspondre à une forme qui inclut notre Origin injecté, par exemple :

Déclenchement côté victime via un paramètre ignoré

Nous cherchons un paramètre ignoré par la cache (trouvé avec Param Miner) :

  • utm_content

Nous réutilisons la cache key et nous plaçons le payload dans utm_content afin de faire servir la ressource empoisonnée tout en visitant lang=en.

Requête finale (telle que nous l’avons utilisée) :

Quand la victime ouvre la page en /login/?lang=en (via la redirection), le contenu empoisonné est servi depuis la cache, et alert(1) s’exécute.

Mis à jour