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

Revision as of 22:44, 25 November 2014

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.

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.

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

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

(to delete rule number one)

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

(to delete all rules).

The example is purposely quite naive, but shows in a simple way the dangers of CSRF.

Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.

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

with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation).

Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL

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.

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.

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.

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.

How to Test

Black Box Testing

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.

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.

Either way, a test case can be constructed as follows:

• let u the URL being tested; for example, 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);
• make sure that the valid user is logged on the application;
• induce him into following the link pointing to the URL to be tested (social engineering involved if you cannot impersonate the user yourself);
• observe the result, i.e. check if the web server executed the request.

Gray Box Testing

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).

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.

Tools

• 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/

References

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

Remediation

The following countermeasures are divided among recommendations to users and to developers.

Users

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

• Logoff immediately after using a web application
• Do not allow the browser to save username/passwords, and do not allow sites to “remember” the log in details.
• 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.

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.

Developers

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.

Other countermeasures, while they do not resolve the issue, contribute to make it harder to exploit:

• Use POST instead of GET. While POST requests may be simulated by means of JavaScript, they make it more complex to mount an attack.
• 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.
• 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).

Related Security Activities

Description of CSRF Vulnerabilities

See the OWASP article on CSRF Vulnerabilities.

How to Avoid CSRF Vulnerabilities

See the OWASP Development Guide article on how to Avoid CSRF Vulnerabilities.

How to Review Code for CSRF Vulnerabilities

See the OWASP Code Review Guide article on how to Review Code for CSRF Vulnerabilities.

How to Prevent CSRF Vulnerabilites

See the OWASP CSRF Prevention Cheat Sheet for prevention measures.