CSRF - Validation Referer vulnérable
CSRF with broken Referer validation
La fonctionnalité de changement d’email du site tente de bloquer les requêtes cross-domain en vérifiant l’en-tête Referer, mais la logique de détection est contournable. L’objectif du labo : héberger sur le serveur d’exploit une page HTML qui réalise un CSRF pour modifier l’adresse e-mail du visiteur.
Compte à utiliser
Utilisateur :
wienerMot de passe :
peter
Si le Referer provient d’un domaine différent, la requête est refusée.
Si le header Referer est absent, la vérification échoue aussi (la requête est refusée).
La validation cherche un match contenant une certaine chaîne dans le
Referer. Elle accepte donc unRefererqui contient cette chaîne, même s’il y a du texte supplémentaire autour.Exemple de chaîne acceptée détectée :
https://JORD4N.PRO0aa7004f039e530680480331005c00f0.web-security-academy.net
Bypass observé
Plutôt que d’envoyer la requête depuis
/exploit, on peut faire en sorte que leReferercontienne la chaîne acceptée (par exemple en construisant une URL qui inclut cette chaîne).
/0aa7004f039e530680480331005c00f0.web-security-academy.net
Les navigateurs imposent des restrictions de sécurité qui empêchent d’envoyer arbitrairement certaines formes de
Referer. Pour forcer l’envoi duReferercomplet depuis la page d’exploit, ajouter la meta-directive suivante dans le<head>:
Cette directive indique au navigateur d’envoyer l’URL de la page d’origine complète comme Referer même en cas de navigation cross-origin (comportement « unsafe »).
Mis à jour
Ce contenu vous a-t-il été utile ?