4.7.5 Tester les CSRF (OTG-SESS-005)

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

Les CSRF sont des attaques qui forcent les utilisateurs à exécuter des actions non désirées sur une application sur laquelle ils sont actuellement authentifiés. Avec un peu d'ingénierie sociale, par exemple en envoyant un lien par email ou messagerie instantanée, un attaquant peut forcer les utilisateurs d'une application web à exécuter les actions qu'il veut. Une exploitation réussie de CSRF peut compromettre les données de l'utilisateur, si celui-ci est un utilisateur normal. Si c'est un compte administrateur qui est visé, une attaque CSRF peut compromettre l'application web dans son ensemble.

Les CSRF reposent sur les éléments suivants :

1) Le comportement du navigateur web concernant le traitement des informations de sessions tels que les cookies et les authentifications HTTP ;
2) La connaissance par l'attaquant d'URLs valides de l'application web ;
3) Le management des sessions applicatives dépendants seulement d'informations connues par le navigateur ;
4) L'existence de tags HTML dont la présence entraine un accès immédiat à des ressources HTTP(S) ; par exemple des tags image img.

Les points 1, 2 et 3 sont essentiels pour la présence de vulnérabilité, alors que le point 4 est accessoire et facilite l'exploitation réelle, mais n'est pas indispensable.

Point 1) Les navigateurs envoient l'information utilisée pour identifier une session utilisateur. Supposons que site est un site hébergeant une application web, et l'utilisateur victime vient de s'authentifier sur site. En réponse, site envoie à victime un cookie qui identifie les requêtes de victime comme appartenant à sa session authentifiée. En gros, une fois que le navigateur a reçu le cookie créé par site, il renverra ce cookie avec toutes les requêtes suivantes destinées à site.

Point 2) Si l'application n'utilise pas les information de session des URLs, cela signifie que les URLs de l'application, leurs paramètres, et valeurs légitimes peuvent être identifiées (par analyse de code, ou en accédant à l'application et en notant les formulaires et URLs embarqués dans HTML/JavaScript).

Point 3) "Connus par le navigateur" renvoit à des informations comme les cookies, les information d'authentification HTTP (tels que Basic Authentication ; et pas les authentifications basées sur des formulaires), qui sont stockées par le navigateur et renvoyées ultérieurement lors de chaque requête vers la partie d'une application qui demande cette authentification. Les vulnérabilités présentées plus bas concernent les applications qui reposent entièrement sur ce genre d'informations pour identifier une session utilisateur.

Prenons un cas simple : des URLs accessibles en GET (bien que cela puisse s'appliquer aussi bien à des requêtes POST). Si victime' s'est déjà authentifié, le cookie sera automatiquement renvoyé avec une autre requête (cf. l'image suivante, où l'utilisateur accède à l'application www.example.com).

La requête GET peut être générée de différentes manières :

• Par l'utilisateur, qui est en train de naviguer l'application web ;
• Par l'utilisateurn qui tappe l'URL directement dans le navigateur ;
• Par l'utilisateur, qui suit un lien (externe à l'application) pointant sur l'URL.

Ces requêtes sont indifférenciables par l'application. La troisième en particulier peut être très dangereuse. Il y a de nombreuses techniques (et vulnérabilités) qui peuvent masquer les propriétés réelles d'un lien. Le lien peut être inséré dans un email, ou apparaître sur un site malicieux vers lequel l'utilisateur est envoyé, par exemple un lien apparaissant dans un contenu hébergé ailleurs (un autre site web, un email en HTML, etc.) et pointant vers une ressource de l'application. Si l'utilisateur clique sur le lien, comme il était déjà authentifié sur l'application web site, le navigateur envoie une requête GET vers l'application, accompagnée de l'information d'authentification (le cookie identifiant de session). Cela exécute donc une opération valide sur l'application, ce qui n'était probablement pas ce que l'utilisateur pensait faire. Pour imaginer les conséquences, il faut penser à un lien malicieux déclenchant un transfert sur une application bancaire.

En utilisant des marqueurs tels que img, comme indiqué dans le point 4 plus haut, il n'est même pas nécessaire que l'utilisateur clique sur un lien particulier. Supposons que l'attaquant envoie un email à l'utilisateur, l'incitant à vitier une URL renvoyant sur une page contenant le code HTML (très simplifié) suivant :

<html><body>

...

<img src=”https://www.company.example/action” width=”0” height=”0”>

...

</body></html>

Quand il va afficher cette page, le navigateur va essayer d'afficher l'image spécifiée, de taille nulle (donc invisible). Cela génère une requête automatique vers l'application web hébergée sur site. Le fait que l'URL de l'image ne pointe pas vers une véritable image n'a aucune importance, de toute façon, sa présence déclenche la requête indiquée dans le champs src. Cela fonctionne à condition que le téléchargement automatique des images ne soit pas désactivé dans le navigateur, mais c'est une configuration commune puisque désactiver les images rendrait inutilisable la plupart des applications web.

Le problème, ici, est la conséquence des faits suivants :

• Il y a des marqueurs HTML dont la présence dans une page provoque des requêtes HTTP automatiques (img est l'un d'eux) ;
• Le navigateur n'a aucun moyen de détecter si la ressource référencée par img n'est en fait pas une image et est illégitime ;
• le chargement d'images est effecif quelque soit la localisation de la prétendue image, c'est-à-dire que le formulaire et l'image elle-même n'ont pas besoin d'être localisés sur le même serveur, ni même dans le même domaine. Bien que ce soit une fonctionnalité pratique, cela rend difficile la compartimentalisation des applications.

C'est le fait qu'un contenu HTML indépendant de l'application web puisse référencer des composants de l'application, et le fait que le navigateur compose automatiquement un requête valide vers l'application, qui permet u ntel type d'attaques. Comme aucun standard n'est défini actuellement, il n'y a aucun moyen d'interdire ce comportement sauf à rendre impossible à l'attaquant de référencer des URLs valides vers l'application. Cela signifie que les URLs doivent contenir des information en rapport avec la session utilisateur, qui ne sont pas supposées être connues de l'attaquant, et ainsi rendre impossible l'identification de telles URLs.

Le problème peut être encore plus grave, puisque l'intégration d'environnement email/navigateur affichant simplement un message email contenant des images pourrait entraîner l'exécution de la requête sur l'application web avec le cookie associé dans le navigateur.

Une obfuscation suplémentaire est possible, en référençant des URLs d'images apparamment valides :

<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>

ici [attacker] est un site controlé par l'attaquant, et utilisant un mécanisme de redirection sur

http://[attacker]/picture.gif to http://[thirdparty]/action.

Les cookies ne sont pas le seul exemple impliqué dans ce type de vulnérabilités. Les applications web dont les informations de session sont entièrement fournies par le navigateur sont aussi vulnérables. Cela inclut les applications reposant uniquement sur le mécanisme d'authentification HTTP, puisque l'information d'authentification est connue du navigateur et est envoyée automatiquement lors de chaque requête. Cela n'inclut PAS l'authentification basée sur formulaire, qui n'intervient qu'une fois et génère une forme quelconque d'information de session (bien sûr, dans ce cas, une telle information est exprimée simplement à l'aide d'un cookie et l'on peut retomber dans les cas précédents).

Exemple de scenarii.

Supposons que la victime est connectée sur une application web de management de firewall. Pour se connecter, un utilisateur doit s'authentifier et les information de session sont stockées dans un cookie.

Supposons que l'application web de management de firewall a une fonction qui permet à un utilisateur authentifié de supprimer une règle désignée par son numéro d'ordre, ou de supprimer toutes les règles de la configuration si l'utilisateur entre '*' (fonctionnalité très dangereuse, mais elle rend l'exemple plus intéressant). La page de suppression est présentée en suivant. Supposons que le formulaire, pour la simplicité de l'exemple, utilise la méthode GET :

https://[target]/fwmgt/delete?rule=1

(pour supprimer le règle numéro 1)

https://[target]/fwmgt/delete?rule=*

(pour supprimer toutes les règles).

L'exemple est volontairement simpliste, mais démontre de manière simple les dangers des CSRF.

Ainsi, si on entre la valeur '*' et que l'on presse le bouton Supprimer, la requête suivante est envoyée.

https://www.company.example/fwmgt/delete?rule=*

avec pour effet de supprimer toutes les règles du firewall (et de se retrouver dans une situation possiblement inconfortable).

Ce n'est pas le seul scénario possible. L'utilisateur aurait pu obtenir les mêmes résultats en envoyant manuellement l'URL

https://[target]/fwmgt/delete?rule=*

ou en cliquant sur un lien pointant, directement ou via une redirection, to l'URL ci-dessus. Ou encore en accèdant à une page HTML contenant un marqueur img pointant sur la même URL.

Dans tous ces cas, si l'utilisateur est actuellement connecté sur l'application de management de firewall, la requête va réussir à modifier la configuration du firewall. On peut imaginer des attaques ciblant des applications sensibles et soumettant des enchères automatiques, procédant à des transferts d'argent, passant des commandes, changeant la configuration de composants logiciels critiques, etc.

Un aspect intéressant est que ces vulnérabilités peuvent être exploitée derrière un firewall ; c'est-à-dire qu'il suffit que le lien attaqué soit accessible à la victime (pas directement par l'attaquant). Cela peut être en particulier n'importe quel server web Intranet ; par exemple, le serveur de management de firewall mentionné plus haut, qui a peu de chances d'être exposé à Internet. Imaginez une attaque CSRF visant une application de surveillance d'une centrale nucléaire. Improbable ? Surement, mais c'est une possibilité.

Des applications "self-vulnerable", c'est-à-dire qui sont utilisées à la fois comme vecteur d'attaque et comme cible (comme des applications webmail), rendent la situation encore plus grave. Si une telle application est vulnérable, l'utilisateur est évidemment connecté lorsqu'il lit un message contenant une attaque CSRF, qui peut viser l'application webmail et la forcer à faire des actions comme supprimer des messages, envoyer des messages de la part de l'utilisateur, etc.

Comment tester

Test en boite noire

En boite noire, le testeur doit connaître les URLs de l'espace restreint (authentifié). S'il possède des crédentiels valides, il peut assumer les deux rôles - attaquent et victime. Dans ce cas, le testeur connaît les URLs simplement en naviguant sur l'application.

Dans le cas contraire, si le testeur n'a pas de crédentiels valides, il doit organiser une attaque réelle, et inciter un utilisateur légitime, authentifié, à ouvrir le lien approprié. Cela peut nécessiter un certain niveau d'ingénierie sociale.

Dans tous les cas, un test peut être conçu comme suit :

• soit u l'URL à tester ; par exemple u = http://www.example.com/action ;
• construire une page contenant la requête HTTP reférençant l'URL u (précisant tous les paramètres nécessaires ; dans le cas d'une requête HTTP GET c'est évident, alors qu'un requête POST nécessitera un peu de JavaScript) ;
• s'assurer que l'utilisateur légitime est bien connecté à l'application ;
• l'inciter à ouvrir le lien pointant sur l'URL à tester (ingénierie sociale, si le testeur ne peut pas incarner l'utilisateur lui-même) ;
• observer le résultat, c'est-à-dire vérifier si le serveur web a exécuté la requête.

Test en boite grise

Auditer l'application pour véirifier si son système de management de session est vulnérable. Si le management de session repose seulement sur des valeurs côté client (information disponibles pour le navigateur), alors l'application est vulnérable. "Valeurs côté client" signifie cookies et crédentiels d'authentification HTTP (Basic Authentication et autres formes d'authentification HTTP ; pas l'authentification basée sur formulaire, qui est une authentification niveau applicatif). Pour qu'une application ne soit pas vulnérable, elle doit contenir des information de session dans ses URL, sous la formes de crédentiels non-identifiables et imprévisibles par l'utilisateur ([3] utilise le terme secret pour désigner cette information).

Les ressources accessible via des requêtes HTTP GET sont facilement vulnérables, bien que les requêtes POST puissent être automatisées via JavaScript et soient aussi vulnérables ; ainsi, l'utilisation de POST seule n'est pas suffisante pour corriger les vulnérabilités CSRF.

Outils

• WebScarab Spider http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
• CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
• Cross Site Requester http://yehg.net/lab/pr0js/pentest/cross_site_request_forgery.php (via img)
• Cross Frame Loader http://yehg.net/lab/pr0js/pentest/cross_site_framing.php (via iframe)
• Pinata-csrf-tool http://code.google.com/p/pinata-csrf-tool/

Références

Whitepapers

• Peter W: "Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt
• Thomas Schreiber: "Session Riding" - http://www.securenet.de/papers/Session_Riding.pdf
• Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan
• Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml
• A Most-Neglected Fact About Cross Site Request Forgery (CSRF) - http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf

Contre-mesures

Les contre-mesures suivantes sont distinguées entre les recommandations pour les utilisateurs et pour les développeurs.

Utilisateurs

Comme les CSRF sont répandues, il est recommandé de suivre de bonnes pratiques pour minimiser les risques. Quelques actions possibles :

• Se déconnecter immédiatement après usage d'une application
• Ne pas autoriser le navigateur à stocker des noms d'utilisateurs et des mots de passe, et ne pas autoriser les sites à "se souvenir" des identifiants de connexion.
• Ne pas utiliser le même navigateur pour accèder des applications sensibles et pour naviguer librement sur Internet ; s'il est nécessaire de faire les deux sur la même machine, utiliser des navigateurs séparés.

Les clients email intégrés avec les navigateurs, ainsi que les lecteurs de newsgroup intégrés avec les navugateurs, comportent des risques additionnels, puisque le simple affichage d'un message peut entraîner l"exécution d'une attaque.

Développeurs

Ajouter des informations de session dans les URLs. Ce qui rend l'attaque possible est le fait que la session est uniquement identifiée par le cookie, qui est automatiquement envoyé par le navigateur. Générer d'autres informations spécifiques à la session au niveau de l'URL rend difficile pour l'attaquant la connaissance de la structure des URLs à ataquer.

D'autre contre-mesures, bien qu'elles ne résouent pas le problème, contribuent à le rendre plus difficile à exploiter :

• Utiliser POST au lieu de GET. Bien que les requêtes POST puissent être simulées au moyen de JavaScript, elles rendent les attaques plus difficiles à concevoir.
• Il en est de même ave les pages de confirmation intermédiaires (telles que : "Etes-vous sûr de vouloir faire cela ?"). Elles peuvent être contournées par l'attaquant, bien qu'elles rendent sont travail u npeu plus complexe. Il ne faut donc pas compter seulement sur ces mesures pour protéger l'application.
• Les mécanismes de déconnexion automatique peuvent un peu limiter l'exposition à ces vulnérabilités, bien qu'au final cela dépende du contexte (un utilisateur qui travaille toute la journée sur une application web bancaire sera évidemment plus à risque qu'un utilisateur occasionnel de la même application).

Autres activités de sécurité

Description des vulnérabilités CSRF

Voir l'article de l'OWASP sur les vulnérabilités CSRF.

Comment éviter les vulnérabilités CSRF

Voir l'article OWASP Development Guide sur Avoid CSRF.

Comment faire des revues de code pour les CSRF

Voir l'article OWASP Code Review Guide sur Review Code for CSRF.

Comment prévenir les vulnérabilités CSRF

Voir l'article OWASP CSRF Prevention Cheat Sheet sur les mesures de prévention.