HTTP-Header XSS : Owasp Juice Shop

Challenge : HTTP-Header XSS

Effectuer une attaque XSS persistée avec <iframe src="javascript:alert(`xss`)"> via un en-tête HTTP.

Analyse

Le site affiche la dernière adresse IP connue d’un utilisateur sur la page /privacy-security/last-login-ip. Cette valeur est mise à jour au moment de la déconnexion, via l’endpoint /rest/saveLogonIp. L’idée est donc d’identifier si un en-tête HTTP peut être manipulé pour contrôler cette valeur, et, si oui, vérifier si l’application applique un filtrage correct.

Etapes de reproduction

1. Observation initiale

Nous nous connectons avec un compte utilisateur standard et consultons /privacy-security/last-login-ip pour voir l’adresse IP actuellement enregistrée.

last-login-ip

2. Interception de la requête

Nous interceptons la requête envoyée à /rest/saveLogonIp au moment de la déconnexion dans Burp Suite.

3. Header injections

Nous testons d’abord X-Forwarded-For — pas d’effet.

Après quelques recherches, notamment dans la documentation du projet Pentest-Book de six2dez, on découvre que certains serveurs peuvent utiliser d’autres en-têtes alternatifs.

[embed]pentest-book/enumeration/web/header-injections.md at master · six2dez/pentest-book Contribute to six2dez/pentest-book development by creating an account on GitHub.github.com

True-Client-IP fonctionne : l’adresse spécifiée est effectivement reflétée dans la page /last-login-ip.

True-Client-IP: 1.2.3.4

True-Client-IP: 1.2.3.4

1.2.3.4

4. Payload XSS

Une fois ce vecteur confirmé, il ne reste plus qu’à remplacer la valeur d’adresse IP par le payload XSS. Le code suivant est utilisé :

<iframe src="javascript:alert(`xss`)">

Après reconnexion et consultation de la page, le script s’exécute correctement. Cela valide la présence d’une XSS persistante exploitée via l’en-tête HTTP True-Client-IP.

xss

Remédiations

• Valider les headers : ne jamais faire confiance aux valeurs reçues, vérifier qu’elles respectent le format attendu (ex. IPv4/IPv6).
• Échapper les sorties : encoder toute donnée provenant d’entrées externes avant de l’afficher dans la page HTML.
• Appliquer des bonnes pratiques : filtrer strictement les entrées, surveiller les logs et utiliser éventuellement une Content Security Policy (CSP) pour limiter l’exécution de scripts.