This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "4.7.5 Tester les CSRF (OTG-SESS-005)"

From OWASP
Jump to: navigation, search
(Created page with "{{Template:OWASP Testing Guide v4}} ==Sommaire== Les CSRF sont des attaques qui forcent les utilisateurs à exécuter des actions non désirées sur une application sur...")
 
 
(3 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
==Sommaire==
 
==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 Cross Site Request Forgeries [[CSRF]] sont des attaques qui forcent les utilisateurs à exécuter des actions non désirées dans une application sur laquelle ils sont actuellement authentifiés. Avec un peu d'ingénierie sociale, par exemple en envoyant un lien par courriel ou messagerie instantanée, un attaquant peut forcer les utilisateurs d'une application web à exécuter les actions qu'il veut. Si un utilisateur normal est visé, une attaque CSRF réussie va compromettre ses données et ses traitements. Si un compte administrateur est visé, c'est l'ensemble de l'application web qui peut être compromise.
  
  
−
Les CSRF reposent sur les éléments suivants :
+
Les CSRF utilisent les éléments suivants :
  
−
1) Web browser behavior regarding the handling of session-related information such as cookies and http authentication information;<br>
+
1) Le mode de traitement, par le navigateur, des informations liées aux sessions, comme que les cookies et authentifications HTTP ; <br>
−
2) Knowledge by the attacker of valid web application URLs;<br>
+
2) La connaissance par l'attaquant d'URLs valides de l'application web ;<br>
−
3) Application session management relying only on information which is known by the browser;<br>
+
3) Le management de sessions applicatives reposant uniquement sur des informations connues du navigateur ; <br>
−
4) Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''.<br>
+
4) La présence de balises HTML donnant un accès direct à des ressources HTTP(S) ; par exemple des balises image ''img''.<br>
  
  
−
Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 is accessory and facilitates the actual exploitation, but is not strictly required.
+
Les points 1, 2 et 3 sont requis pour la présence de la vulnérabilité, alors que le point 4 facilite l'exploitation réelle, mais n'est pas indispensable.
  
  
−
Point 1) Browsers automatically send information which is used to identify a user session. Suppose ''site'' is a site hosting a web application, and the user ''victim'' has just authenticated himself to ''site''. In response, ''site'' sends ''victim'' a cookie which identifies  requests sent by ''victim'' as belonging to ''victim’s'' authenticated session. Basically, once the browser receives the cookie set by ''site'', it will automatically send it along with any further requests directed to ''site''.
+
Point 1) Les navigateurs envoient l'information utilisée pour identifier une session utilisateur. Supposons que ''site'' héberge une application web, et que l'utilisateur ''victime'' s'est authentifié 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 joindra ce cookie à toutes les requêtes suivantes destinées à ''site''.
  
  
−
Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters, and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).
+
Point 2) Si l'application n'utilise pas d'informations de session intégrées dans les 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 aux formulaires et URLs embarqués dans HTML/JavaScript).
  
  
−
Point 3)"Known by the browser” refers to information such as cookies, or http-based authentication information (such as Basic Authentication; and not form-based authentication), which are stored by the browser and subsequently resent at each request directed towards an application area requesting that authentication. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session.
+
Point 3) Les informations connues par le navigateur comprennent les cookies, les informations d'authentification HTTP (telles que l'Authentification Basique ; et pas les authentifications basées sur des formulaires), qui sont stockées par le navigateur et renvoyées automatiquement à chaque requête ultérieure à la partie de l'application nécessitant 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.
  
  
−
Suppose, for simplicity's sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If ''victim'' has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).
+
Prenons un cas simple : des URLs accessibles en GET (bien que cela puisse s'appliquer aussi bien à des requêtes POST). Si l'utilisateur ''victime'' est déjà authentifié, son cookie sera automatiquement joint à une autre requête (cf. l'image suivante, où l'utilisateur accède à l'application www.example.com).
  
  
Line 32: Line 32:
  
  
−
The GET request could be originated in several different ways:
+
La requête GET peut être générée de différentes manières :
  
−
* by the user, who is using the actual web application;
+
* Par l'utilisateur, qui est en train d'utiliser l'application web ;
−
* by the user, who types the URL directly in the browser;
+
* Par l'utilisateur qui saisit directement l'URL dans le navigateur ;
−
* by the user, who follows a link (external to the application) pointing to the URL.
+
* 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 courriel, ou sur un site malicieux vers lequel l'utilisateur est envoyé, par exemple un lien intégré dans un contenu hébergé ailleurs (un autre site web, un courriel 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.
  
−
These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on ''site'', the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen. Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications.
 
  
−
 
+
En utilisant des balises 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 courriel à l'utilisateur, l'incitant à visiter une URL renvoyant sur une page contenant le code HTML (très simplifié) suivant :
−
By using a tag such as ''img'', as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:
 
  
 
<pre>
 
<pre>
Line 57: Line 56:
  
  
−
What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results in a request being automatically sent to the web application hosted on ''site''. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the ''src'' field anyway. This happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability.
+
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 habituellement le cas puisque désactiver les images rendrait la plupart des applications web inutilisables.
  
  
−
The problem here is a consequence of the following facts:
+
Le problème, ici, est la conséquence des faits suivants :
  
−
* there are HTML tags whose appearance in a page result in automatic http request execution (''img'' being one of those);
+
* Il y a des balises HTML dont la présence dans une page provoque des requêtes HTTP automatiques (''img'' par exemple) ;
−
* the browser has no way to tell that the resource referenced by ''img ''is not actually an image and is in fact not legitimate;
+
* Le navigateur n'a aucun moyen de détecter que la ressource référencée par ''img'' n'est en réalité pas une image et est illégitime ;
−
* image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.
+
* le chargement d'images est effectif 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 le cloisonnement les applications.
  
  
−
It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.
+
Un tel type d'attaque est rendu possible par le fait qu'un contenu HTML externe à l'application puisse référencer des composants de l'application, et que le navigateur construise automatiquement des requêtes valides vers l'application. 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 informations 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.
  
  
−
The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.
+
Le problème peut être encore plus grave, puisque l'intégration d'environnement courriel/navigateur affichant simplement un message électronique contenant des images pourrait appeler l'application web avec le cookie associé au navigateur.
  
  
−
Things may be obfuscated further, by referencing seemingly valid image URLs such as
+
On peut encore mieux camoufler l'attaque, en référençant des URLs d'images d'apparence valide :
  
 
  <img src=”https://[attacker]/picture.gif” width=”0” height=”0”>
 
  <img src=”https://[attacker]/picture.gif” width=”0” height=”0”>
  
−
where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on
+
Ici [attacker] est un site contrôlé par l'attaquant, et en utilisant un mécanisme de redirection
−
  http://[attacker]/picture.gif to http://[thirdparty]/action.
+
  de http://[attacker]/picture.gif vers http://[thirdparty]/action.
  
  
−
Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form-based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).
+
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 gérées uniquement 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 avec chaque requête. Cela ne concerne PAS l'authentification basée sur formulaire, qui n'intervient qu'une fois et génère une forme quelconque d'information de session (si une telle information est exprimée uniquement à l'aide d'un cookie, l'on peut bien sûr retomber dans les cas précédents).
  
  
−
'''Sample scenario.'''
+
'''Exemple de scenario.'''
  
−
Let’s suppose that the victim is logged on to a firewall web management application. To log in, a user has to authenticate himself and session information is stored in a cookie.
+
Supposons que la victime soit connectée sur une application web de configuration de pare-feu. Pour se connecter, un utilisateur doit s'authentifier et les informations de session sont stockées dans un cookie.
  
  
−
Let's suppose the firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form
+
Supposons que l'application web de configuration de pare-feu ait 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 ci-dessous. Supposons que le formulaire, pour la simplicité de l'exemple, utilise la méthode GET :
  
 
  https://[target]/fwmgt/delete?rule=1
 
  https://[target]/fwmgt/delete?rule=1
  
−
(to delete rule number one)
+
(pour supprimer le règle numéro 1)
  
 
  https://[target]/fwmgt/delete?rule=*
 
  https://[target]/fwmgt/delete?rule=*
  
−
(to delete all rules).
+
(pour supprimer toutes les règles).
  
  
−
The example is purposely quite naive, but shows in a simple way the dangers of CSRF.
+
L'exemple est volontairement simpliste, mais démontre de manière simple les dangers des CSRF.
  
 
<center>[[image:Session Riding Firewall Management.gif]]</center>
 
<center>[[image:Session Riding Firewall Management.gif]]</center>
  
  
−
Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.
+
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=*
 
  https://www.company.example/fwmgt/delete?rule=*
  
  
−
with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation).
+
avec pour effet de supprimer toutes les règles du pare-feu (et de se retrouver dans une situation potentiellement inopportune).
  
 
<center>[[image:Session Riding Firewall Management 2.gif]]</center>
 
<center>[[image:Session Riding Firewall Management 2.gif]]</center>
  
  
−
Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL  
+
Ce n'est pas le seul scénario possible. L'utilisateur aurait pu obtenir les mêmes résultats en construisant l'URL manuellement :
  
 
  https://[target]/fwmgt/delete?rule=*
 
  https://[target]/fwmgt/delete?rule=*
  
  
−
or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded ''img'' tag pointing to the same URL.
+
Ou en cliquant sur un lien pointant, directement ou via une redirection, vers l'URL ci-dessus ; ou encore en accédant à une page HTML contenant une balise ''img'' pointant sur la même URL.
  
  
−
In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall. One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.
+
Dans tous ces cas, si l'utilisateur est effectivement connecté sur l'application de configuration de pare-feu, la requête va réussir à modifier la configuration du pare-feu. 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.
  
  
−
An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet. Imagine a CSRF attack targeting an application monitoring a nuclear power plant. Sounds far fetched? Probably, but it is a possibility.
+
Un aspect intéressant est que ces vulnérabilités peuvent être exploitées derrière un pare-feu ; c'est-à-dire qu'il suffit que le lien attaqué soit accessible par la victime (et non directement par l'attaquant). Cela peut être en particulier n'importe quel server web Intranet ; par exemple, le serveur de configuration de pare-feu 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. C'est improbable, mais c'est une possibilité.
  
  
−
Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.
+
Des applications intrinsèquement vulnérables, pouvant être 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.
  
  
  
−
==How to Test==
+
==Comment tester==
  
−
===Black Box Testing===
+
===Test en boite noire===
  
−
For a black box test the tester must know URLs in the restricted (authenticated) area. If they possess valid credentials, they can assume both roles – the attacker and the victim. In this case, testers know the URLs to be tested just by browsing around the application.
+
En boite noire, le testeur doit connaître les URLs de l'espace restreint (authentifié). S'il possède des accès valides, il peut assumer les deux rôles - attaquant et victime. Dans ce cas, le testeur découvre les URLs en naviguant simplement sur l'application.
  
  
−
Otherwise, if testers don’t have valid credentials available, they have to organize a real attack, and so induce a legitimate, logged in user into following an appropriate link. This may involve a substantial level of social engineering.
+
Au contraire, si le testeur n'a pas d'accès valides, il doit organiser une attaque réelle, et inciter un utilisateur légitime, authentifié, à ouvrir un lien approprié. Cela peut nécessiter un certain niveau d'ingénierie sociale.
  
  
−
Either way, a test case can be constructed as follows:
+
Dans tous les cas, un test peut être conçu comme suit :
  
−
* let ''u'' the URL being tested; for example, u = http://www.example.com/action
+
* soit ''u'' l'URL à tester ; par exemple u = http://www.example.com/action ;
−
* build an html page containing the http request referencing URL u (specifying all relevant parameters; in the case of http GET this is straightforward, while to a POST request you need to resort to some Javascript);
+
* construire une page contenant la requête HTTP reférençant l'URL u (précisant tous les paramètres nécessaires ; c'est trivial dans le cas d'une requête HTTP GET, alors qu'une requête POST nécessitera un peu de JavaScript) ;
−
* make sure that the valid user is logged on the application;
+
* s'assurer que l'utilisateur légitime est bien connecté à l'application ;
−
* induce him into following the link pointing to the URL to be tested (social engineering involved if you cannot impersonate the user yourself);
+
* l'inciter à ouvrir le lien pointant sur l'URL à tester (par ingénierie sociale, si le testeur ne peut pas se faire passer lui-même pour l'utilisateur) ;
−
* observe the result, i.e. check if the web server executed the request.
+
* observer le résultat, c'est-à-dire vérifier si le serveur web a exécuté la requête.
  
  
−
===Gray Box Testing===
+
===Test en boite grise===
  
−
Audit the application to ascertain if its session management is vulnerable. If session management relies only on client side values (information available to the browser), then the application is vulnerable. "Client side values” mean cookies and HTTP authentication credentials (Basic Authentication and other forms of HTTP authentication; not form-based authentication, which is an application-level authentication). For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user ([3] uses the term ''secret'' to refer to this piece of information).
+
Auditer l'application pour vérifier si son système de gestion de session est vulnérable. Si la gestion de session repose seulement sur des valeurs côté client (informations disponibles pour le navigateur), alors l'application est vulnérable. "Valeurs côté client" signifie cookies et informations d'authentification HTTP (Authentication Basique et autres formes d'authentification HTTP ; pas l'authentification basée sur formulaire, qui est une authentification au niveau applicatif). Pour qu'une application ne soit pas vulnérable, elle doit contenir des informations de session dans ses URLs, sous une forme non-identifiable et non-prévisible par l'utilisateur ([3] utilise le terme ''secret'' pour désigner ces informations).
  
  
−
Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automated via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.
+
Les ressources accessibles par requêtes HTTP GET sont facilement vulnérables, et comme les requêtes POST puissent être automatisées en JavaScript et soient aussi vulnérables ; l'utilisation de POST uniquement ne suffit pas à éviter les vulnérabilités CSRF.
  
  
−
==Tools==
+
==Outils==
 
* WebScarab Spider http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
 
* WebScarab Spider http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
 
* CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
 
* CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
Line 168: Line 167:
  
  
−
==References==
+
==Références==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
 
* Peter W: "Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt
 
* Peter W: "Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt
Line 174: Line 173:
 
* Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan
 
* Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan
 
* Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml  
 
* 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  http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf ]
+
* A Most-Neglected Fact About Cross Site Request Forgery (CSRF) - [http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf]
  
−
==Remediation==
+
==Contre-mesures==
  
−
The following countermeasures are divided among recommendations to users and to developers.
+
Ci-dessous, des contre-mesures pour les utilisateurs et les développeurs.
  
  
−
<u>Users</u>
+
<u>Utilisateurs</u>
  
−
Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:
+
Comme les attaques CSRF sont répandues, il est recommandé de suivre de bonnes pratiques pour minimiser les risques. Actions possibles :
  
−
* Logoff immediately after using a web application
+
* Se déconnecter immédiatement après utilisation d'une application
−
* Do not allow the browser to save username/passwords, and do not allow sites to “remember” the log in details.
+
* 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.
−
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if it is necessary to do both things at the same machine, do them with separate browsers.
+
* 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.
  
  
−
Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.
+
L'intégration de clients de messagerie et de lecteurs de newsgroups avec les navigateurs introduit des risques supplémentaires, puisque le simple affichage d'un message peut entraîner l'exécution d'une attaque.
  
  
−
<u>Developers</u>
+
<u>Développeurs</u>
  
−
Add session-related information to the URL. What makes the attack possible is the fact that the session is uniquely identified by the cookie, which is automatically sent by the browser. Having other session-specific information being generated at the URL level makes it difficult to the attacker to know the structure of URLs to attack.
+
Il faut ajouter des informations de session dans les URLs. L'attaque est rendue possible parce 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 à attaquer.
  
  
−
Other countermeasures, while they do not resolve the issue, contribute to make it harder to exploit:
+
Il y existe d'autres contre-mesures qui, bien qu'elles ne résolvent pas le problème, contribuent à le rendre plus difficile à exploiter :
  
−
*Use POST instead of GET. While POST requests may be simulated by means of JavaScript, they make it more complex to mount an attack.  
+
* 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.
−
*The same is true with intermediate confirmation pages (such as: “Are you sure you really want to do this?” type of pages). They can be bypassed by an attacker, although they will make their work a bit more complex. Therefore, do not rely solely on these measures to protect your application.  
+
* Il en est de même avec 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 son travail un peu plus complexe. Il ne faut donc pas compter seulement sur ces mesures pour protéger l'application.
−
*Automatic log out mechanisms somewhat mitigate the exposure to these vulnerabilities, though it ultimately depends on the context (a user who works all day long on a vulnerable web banking application is obviously more at risk than a user who uses the same application occasionally).
+
* 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).
  
−
==Related Security Activities==
+
==Autres activités de sécurité==
  
−
===Description of CSRF Vulnerabilities===
+
===Description des vulnérabilités CSRF===
  
−
See the OWASP article on [[CSRF]] Vulnerabilities.
+
Voir l'article de l'OWASP sur les vulnérabilités [[CSRF]].
  
  
−
===How to Avoid CSRF Vulnerabilities===
+
===Comment éviter les vulnérabilités CSRF===
  
−
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to CSRF |Avoid CSRF]] Vulnerabilities.
+
Voir l'article [[:Category:OWASP Guide Project|OWASP Development Guide]] sur [[Guide to CSRF |Eviter les CSRF]].
  
  
−
===How to Review Code for CSRF Vulnerabilities===
+
===Comment faire des revues de code pour les CSRF===
  
−
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Review Code for CSRF]] Vulnerabilities.
+
Voir l'article [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] sur [[Reviewing code for Cross-Site Request Forgery issues |Revue de code pour les CSRF]].
  
  
−
===How to Prevent CSRF Vulnerabilites===
+
===Comment prévenir les vulnérabilités CSRF===
  
−
See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.
+
Voir l'article [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] sur les mesures de prévention.

Latest revision as of 13:55, 13 January 2015

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 Cross Site Request Forgeries CSRF sont des attaques qui forcent les utilisateurs à exécuter des actions non désirées dans une application sur laquelle ils sont actuellement authentifiés. Avec un peu d'ingénierie sociale, par exemple en envoyant un lien par courriel ou messagerie instantanée, un attaquant peut forcer les utilisateurs d'une application web à exécuter les actions qu'il veut. Si un utilisateur normal est visé, une attaque CSRF réussie va compromettre ses données et ses traitements. Si un compte administrateur est visé, c'est l'ensemble de l'application web qui peut être compromise.


Les CSRF utilisent les éléments suivants :

1) Le mode de traitement, par le navigateur, des informations liées aux sessions, comme que les cookies et authentifications HTTP ;
2) La connaissance par l'attaquant d'URLs valides de l'application web ;
3) Le management de sessions applicatives reposant uniquement sur des informations connues du navigateur ;
4) La présence de balises HTML donnant un accès direct à des ressources HTTP(S) ; par exemple des balises image img.


Les points 1, 2 et 3 sont requis pour la présence de la vulnérabilité, alors que le point 4 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 héberge une application web, et que l'utilisateur victime s'est authentifié 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 joindra ce cookie à toutes les requêtes suivantes destinées à site.


Point 2) Si l'application n'utilise pas d'informations de session intégrées dans les 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 aux formulaires et URLs embarqués dans HTML/JavaScript).


Point 3) Les informations connues par le navigateur comprennent les cookies, les informations d'authentification HTTP (telles que l'Authentification Basique ; et pas les authentifications basées sur des formulaires), qui sont stockées par le navigateur et renvoyées automatiquement à chaque requête ultérieure à la partie de l'application nécessitant 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 l'utilisateur victime est déjà authentifié, son cookie sera automatiquement joint à une autre requête (cf. l'image suivante, où l'utilisateur accède à l'application www.example.com).


Session riding.GIF


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

  • Par l'utilisateur, qui est en train d'utiliser l'application web ;
  • Par l'utilisateur qui saisit directement l'URL 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 courriel, ou sur un site malicieux vers lequel l'utilisateur est envoyé, par exemple un lien intégré dans un contenu hébergé ailleurs (un autre site web, un courriel 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 balises 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 courriel à l'utilisateur, l'incitant à visiter 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 habituellement le cas puisque désactiver les images rendrait la plupart des applications web inutilisables.


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

  • Il y a des balises HTML dont la présence dans une page provoque des requêtes HTTP automatiques (img par exemple) ;
  • Le navigateur n'a aucun moyen de détecter que la ressource référencée par img n'est en réalité pas une image et est illégitime ;
  • le chargement d'images est effectif 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 le cloisonnement les applications.


Un tel type d'attaque est rendu possible par le fait qu'un contenu HTML externe à l'application puisse référencer des composants de l'application, et que le navigateur construise automatiquement des requêtes valides vers l'application. 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 informations 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 courriel/navigateur affichant simplement un message électronique contenant des images pourrait appeler l'application web avec le cookie associé au navigateur.


On peut encore mieux camoufler l'attaque, en référençant des URLs d'images d'apparence valide : 

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

Ici [attacker] est un site contrôlé par l'attaquant, et en utilisant un mécanisme de redirection 

de http://[attacker]/picture.gif vers 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 gérées uniquement 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 avec chaque requête. Cela ne concerne PAS l'authentification basée sur formulaire, qui n'intervient qu'une fois et génère une forme quelconque d'information de session (si une telle information est exprimée uniquement à l'aide d'un cookie, l'on peut bien sûr retomber dans les cas précédents).


Exemple de scenario.

Supposons que la victime soit connectée sur une application web de configuration de pare-feu. Pour se connecter, un utilisateur doit s'authentifier et les informations de session sont stockées dans un cookie.


Supposons que l'application web de configuration de pare-feu ait 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 ci-dessous. 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.

Session Riding Firewall Management.gif


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 pare-feu (et de se retrouver dans une situation potentiellement inopportune).

Session Riding Firewall Management 2.gif


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

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


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


Dans tous ces cas, si l'utilisateur est effectivement connecté sur l'application de configuration de pare-feu, la requête va réussir à modifier la configuration du pare-feu. 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ées derrière un pare-feu ; c'est-à-dire qu'il suffit que le lien attaqué soit accessible par la victime (et non directement par l'attaquant). Cela peut être en particulier n'importe quel server web Intranet ; par exemple, le serveur de configuration de pare-feu 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. C'est improbable, mais c'est une possibilité.


Des applications intrinsèquement vulnérables, pouvant être 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 accès valides, il peut assumer les deux rôles - attaquant et victime. Dans ce cas, le testeur découvre les URLs en naviguant simplement sur l'application.


Au contraire, si le testeur n'a pas d'accès valides, il doit organiser une attaque réelle, et inciter un utilisateur légitime, authentifié, à ouvrir un 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 ; c'est trivial dans le cas d'une requête HTTP GET, alors qu'une 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 (par ingénierie sociale, si le testeur ne peut pas se faire passer lui-même pour l'utilisateur) ;
  • 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érifier si son système de gestion de session est vulnérable. Si la gestion de session repose seulement sur des valeurs côté client (informations disponibles pour le navigateur), alors l'application est vulnérable. "Valeurs côté client" signifie cookies et informations d'authentification HTTP (Authentication Basique et autres formes d'authentification HTTP ; pas l'authentification basée sur formulaire, qui est une authentification au niveau applicatif). Pour qu'une application ne soit pas vulnérable, elle doit contenir des informations de session dans ses URLs, sous une forme non-identifiable et non-prévisible par l'utilisateur ([3] utilise le terme secret pour désigner ces informations).


Les ressources accessibles par requêtes HTTP GET sont facilement vulnérables, et comme les requêtes POST puissent être automatisées en JavaScript et soient aussi vulnérables ; l'utilisation de POST uniquement ne suffit pas à éviter les vulnérabilités CSRF.


Outils


Références

Whitepapers

Contre-mesures

Ci-dessous, des contre-mesures pour les utilisateurs et les développeurs.


Utilisateurs

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

  • Se déconnecter immédiatement après utilisation 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.


L'intégration de clients de messagerie et de lecteurs de newsgroups avec les navigateurs introduit des risques supplémentaires, puisque le simple affichage d'un message peut entraîner l'exécution d'une attaque.


Développeurs

Il faut ajouter des informations de session dans les URLs. L'attaque est rendue possible parce 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 à attaquer.


Il y existe d'autres contre-mesures qui, bien qu'elles ne résolvent 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 avec 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 son travail un peu 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 Eviter les CSRF.


Comment faire des revues de code pour les CSRF

Voir l'article OWASP Code Review Guide sur Revue de code pour les CSRF.


Comment prévenir les vulnérabilités CSRF

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

Retrieved from "https://wiki.owasp.org/index.php?title=4.7.5_Tester_les_CSRF_(OTG-SESS-005)&oldid=187967"