{"id":169,"date":"2014-06-01T22:18:19","date_gmt":"2014-06-01T21:18:19","guid":{"rendered":"http:\/\/www.mickael-franc.fr\/blog\/?p=169"},"modified":"2015-11-13T15:13:08","modified_gmt":"2015-11-13T14:13:08","slug":"owasp-cross-site-request-forgery-csrf-ou-xsrf","status":"publish","type":"post","link":"https:\/\/www.mickael-franc.fr\/blog\/owasp-cross-site-request-forgery-csrf-ou-xsrf\/","title":{"rendered":"OWASP \/ Cross-site request forgery (CSRF ou XSRF)"},"content":{"rendered":"

\"CSRF<\/a>Dans ce troisi\u00e8me article de la s\u00e9rie consacr\u00e9e aux failles applicatives<\/a>, j\u2019aborde les failles CSRF au travers de l\u2019OWASP. Vous d\u00e9couvrirez ces failles et apprendrez \u00e0 les d\u00e9tecter. Vous verrez enfin les moyens de vous en pr\u00e9munir.<\/p>\n

<\/p>\n

Introduction<\/h2>\n

L\u2019objet de l\u2019attaque CSRF est de forcer des utilisateurs \u00e0 ex\u00e9cuter une ou plusieurs requ\u00eates non d\u00e9sir\u00e9es sur un site donn\u00e9, forg\u00e9es par un utilisateur malintentionn\u00e9. La victime choisie aura les privil\u00e8ges n\u00e9cessaires \u00e0 l\u2019ex\u00e9cution de la requ\u00eate, voire une session encore active.
\nForger une requ\u00eate reviens \u00e0 cr\u00e9er \/ falsifier une requ\u00eate HTTP (par le biais d\u2019une URL ou d\u2019un formulaire principalement) pointant sur une action pr\u00e9cise interne au site et n\u00e9faste pour la victime.
\nConcr\u00e8tement, une ressource vuln\u00e9rable aux attaques CSRF est repr\u00e9sent\u00e9e par toutes ressources disponibles directement ET sans \u00e9tape interm\u00e9diaire (ex: g\u00e9n\u00e9ration de cl\u00e9\/jeton d\u2019autorisation d\u2019acc\u00e8s) sur un SI.<\/p>\n

Rappel<\/h2>\n

L\u2019OWASP (Open Web Application Security Project) dispose d\u2019un projet de classification des failles les plus couramment utilis\u00e9es par des utilisateurs malintentionn\u00e9s sur Internet. Ce document est accompagn\u00e9 d\u2019une qualification des menaces list\u00e9es et d\u2019une explication sur l\u2019exploitation.<\/p>\n

Ce projet se nomme le \u201cTop Ten\u00a0\u00bb (et sort chaque ann\u00e9e si le classement \u00e9volue), et est disponible \u00e0 cette adresse : https:\/\/www.owasp.org\/index.php\/Category:OWASP_Top_Ten_Project<\/a><\/p>\n

En 2010, les failles de type CSRF sont class\u00e9es \u00e0 la 5\u00e8me position, tandis que cette ann\u00e9e elles arrivent en 8\u00e8me position.<\/p>\n

Qualification de la menace<\/h2>\n

On pourrait presque qualifier la faille CSRF de \u201csur-couche\u201d ou \u201cvecteur d’aggravation\u201d, car elle aura un impact seulement si une autre vuln\u00e9rabilit\u00e9 est pr\u00e9sente dans le SI (le vecteur d\u2019attaque est souvent soit une XSS soit du phishing).
\n Remarque :<\/span> Une attaque CSRF sera d’autant plus dangereuse qu’il y a de fonctionnalit\u00e9s vuln\u00e9rables expos\u00e9es par le SI.<\/p>\n\n\n\n\n\n\n\n\n
\n

Agent de menace<\/span>
\n<\/strong><\/p>\n<\/td>\n

\n

_<\/span><\/p>\n<\/td>\n

\n

Consid\u00e9rez n\u2019importe quel individu pouvant tromper vos utilisateurs en soumettant une requ\u00eate \u00e0 votre site. N\u2019importe quel site ou autre source HTML auxquels vos utilisateurs pourraient acc\u00e9der.<\/p>\n<\/td>\n<\/tr>\n

\n

Vecteur d\u2019attaque<\/span>
\n<\/strong><\/p>\n<\/td>\n

\n

Facilit\u00e9 Moyenne<\/span><\/p>\n<\/td>\n

\n

L\u2019attaquant forge une requ\u00eate HTTP et am\u00e8ne une victime \u00e0 la soumettre via une balise d\u2019image, une XSS, du phishing, ou de nombreuses autres techniques. Si l\u2019utilisateur est authentifi\u00e9, l\u2019attaque est un succ\u00e8s.<\/p>\n<\/td>\n<\/tr>\n

\n

Vraisemblance de la vuln\u00e9rabilit\u00e9<\/span>
\n<\/strong><\/p>\n<\/td>\n

\n

R\u00e9pandue<\/span><\/p>\n<\/td>\n

\n

CSRF prend avantage des applications web qui permettent aux attaquants de pr\u00e9dire les d\u00e9tails d\u2019une action particuli\u00e8re.<\/p>\n<\/td>\n<\/tr>\n

\n

D\u00e9tection de la vuln\u00e9rabilit\u00e9<\/span><\/strong><\/p>\n<\/td>\n

\n

Facile
\n<\/span><\/p>\n<\/td>\n

\n

Les attaquants peuvent cr\u00e9er des pages web malicieuses qui g\u00e9n\u00e8rent des requ\u00eates forg\u00e9es, qui ne sont pas distinguables des l\u00e9gitimes. La d\u00e9tection des CSRF est assez facile via un test de p\u00e9n\u00e9tration ou analyse de code.<\/p>\n<\/td>\n<\/tr>\n

\n

Impact technique<\/span><\/strong><\/p>\n<\/td>\n

\n

Moyen<\/span><\/p>\n<\/td>\n

\n

Les attaquants peuvent faire ex\u00e9cuter n\u2019importe quelle type de fonctionnalit\u00e9 pr\u00e9sente dans le SI, \u00e0 laquelle la victime aurait acc\u00e8s.<\/p>\n<\/td>\n<\/tr>\n

\n

Impact m\u00e9tier
\n<\/span><\/strong><\/p>\n<\/td>\n

\n

_<\/span><\/p>\n<\/td>\n

\n

Tout d\u00e9pend de l\u2019action ex\u00e9cut\u00e9e.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

\"Attaque<\/a><\/p>\n

Exemples d\u2019attaques<\/h2>\n

Cas fictifs<\/strong><\/h3>\n

Service bancaire<\/h4>\n

Imaginez un bouton sur votre site de banque en ligne permettant d\u2019effectuer un virement sur un compte ext\u00e9rieur ayant pour URL :<\/p>\n

http:\/\/www.mabanque.com\/transaction.php?dest=ID12345&somme=2000<\/a><\/p>\n

O\u00f9 le param\u00e8tre \u00ab\u00a0dest\u00a0\u00bb est l\u2019identifiant du destinataire de la transaction et \u00ab\u00a0somme\u00a0\u00bb, le montant de la transaction. Admettons ensuite que Mme Lambda soit all\u00e9e voir ses relev\u00e9s bancaires et que sa session soit toujours active. Imaginons ensuite qu\u2019un utilisateur malveillant, connaissant la victime, ait d\u00e9cid\u00e9 de lui envoyer un mail (en usurpant l\u2019adresse e-mail d\u2019un de ses proches).
\nL\u2019e-mail contiendrait un lien vers cette action et avec pour destinataire son identifiant de compte. Si Mme Lambda clique sur le lien, alors la transaction sera effectu\u00e9e contre son gr\u00e9.
\nSi cette attaque est coupl\u00e9e d\u2019une attaque XSS (en utilisant par exemple une balise img) sur le site bancaire, alors chaque utilisateur connect\u00e9 sur le site sera victime de ce d\u00e9tournement de fonds.<\/p>\n

Webmail<\/h4>\n

M\u00eame exemple pour un Webmail, avec un lien permettant de supprimer vos e-mails.<\/p>\n

Bot<\/h4>\n

Un robot qui a pour objectif de polluer votre base de donn\u00e9es en \u201cspammant\u201d. Le robot r\u00e9cup\u00e8rerait votre page une fois, analyserait les champs de formulaire, et enverrait une multitude de requ\u00eates avec des valeurs quelconques.<\/p>\n

Social Network<\/h4>\n

De nos jours, tout le monde conna\u00eet les boutons de partage li\u00e9s aux r\u00e9seaux sociaux (tel que les boutons \u00ab\u00a0J\u2019aime\u00a0\u00bb de Facebook, \u201c+1\u201d de Google+, etc). Ces boutons permettent d\u2019ajouter une
\npage \u00e0 nos favoris, sauf qu\u2019ici l\u2019utilisateur est conscient de l\u2019action effectu\u00e9e en cliquant dessus.
\nOr, il est possible pour un utilisateur malintentionn\u00e9 de faire d\u00e9river le comportement initial de ces boutons pour porter atteinte \u00e0 la victime via des techniques d\u00eetes de \u201cPhishing\u201d ou \u201cClickjacking\u201d :<\/p>\n

Cas n\u00b01<\/i><\/h5>\n

Imaginons qu\u2019un utilisateur malveillant conserve le rendu visuel de ce bouton mais en changeant son comportement (ex: modifiction de l\u2019URL), un utilisateur habitu\u00e9 pourrait cliquer instinctivement (par habitude) dessus et ex\u00e9cuterai l\u2019action forg\u00e9e par le pirate (ex: redirection sur un site pi\u00e9g\u00e9, exploitation de la session active de la victime, etc.).<\/p>\n

Cas n\u00b02<\/em><\/h5>\n

Ce bouton pourrait \u00eatre camoufl\u00e9 (sans changer son URL) par dessus un \u00e9l\u00e9ment banal et cliquable sur un site vuln\u00e9rable. Lorsque l\u2019utilisateur pensera cliquer sur un \u00e9l\u00e9ment souhait\u00e9, il cliquera en fait sur l\u2019\u00e9l\u00e9ment cach\u00e9 par le pirate et ex\u00e9cutera par cons\u00e9quent l\u2019action forg\u00e9e. Ce camouflage est possible par exemple via la directive CSS : \u201copacity: 0.001;\u201d, l\u2019\u00e9l\u00e9ment cach\u00e9 sera invisible pour une personne, mais la propagation des \u00e9v\u00e8nements au sein du DOM restera identique.<\/p>\n

Anecdote :<\/span> Une bien mauvaise blague serait de mettre en pratique cette technique sur un site de vid\u00e9os douteuses en streaming \u00e0 la place du bouton lecture… L\u2019impact ici est un pr\u00e9judice moral. Ce genre de d\u00e9rive \u00e0 \u00e9t\u00e9 point\u00e9e du doigt dans un article du site \u201cPcInpact\u201d, cf : http:\/\/www.pcinpact.com\/news\/62398-bouton-jaime-like-facebook-cdrole.htm<\/a> ou encore :
\nhttp:\/\/www.mycommunitymanager.fr\/arretez-de-vous-faire-avoir-sur-facebook\/<\/a><\/p>\n

Cas pratique<\/strong><\/h3>\n

Site \u00e9ditorial<\/h4>\n

Prenons pour exemple un site \u00e9ditorial lambda disposant :<\/p>\n

– D\u2019une gestion des commentaires enrichie, autorisant certains \u00e9l\u00e9ments HTML tels que les paragraphes, les sauts de ligne, les images, etc.
\n– D\u2019une interface d\u2019administration des commentaires (ou chaque commentaire est affich\u00e9 directement une fois connect\u00e9 sur cette interface)
\n– D\u2019une URL de d\u00e9connexion du type : http:\/\/www.foobar.net\/logout.php<\/p>\n

Il suffirait que l\u2019utilisateur malveillant injecte dans son commentaire une image qui pointerait vers l\u2019URL de d\u00e9connexion pour emp\u00eacher toute administration du site : l\u2019utilisateur serait d\u00e9connect\u00e9 tout de suite apr\u00e8s s\u2019\u00eatre connect\u00e9.
\nExemple de commentaire :<\/span>
\nCeci est une attaque CSRF<\/p>\n

Remarque :<\/span> Il s\u2019agit ici d\u2019une attaque CSRF qui passe par une \u201cstored XSS\u201d (ou XSS stock\u00e9e).<\/p>\n

Comment se prot\u00e9ger ?<\/h2>\n

Le projet OWASP nous propose deux approches pour se pr\u00e9munir des attaques CSRF : https:\/\/www.owasp.org\/index.php\/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet<\/a><\/p>\n

La 1\u00e8re solution est bas\u00e9e sur le \u201cdesign pattern\u201d (ou patron de conception) : \u201cSynchonizer Token Pattern\u201d (cf : http:\/\/www.corej2eepatterns.com\/Design\/PresoDesign.htm<\/a>), cette solution requiert la session d\u2019un utilisateur courant. Il s\u2019agit de la solution pr\u00e9conis\u00e9e.<\/p>\n

Dans un deuxi\u00e8me temps vous seront propos\u00e9es plusieurs autres solutions ou visions du probl\u00e8mes dans le cas d\u2019une application \u201csans-\u00e9tat\u201d, c’est-\u00e0-dire qu\u2019aucun param\u00e8tre n\u2019est conserv\u00e9 depuis le serveur pour le client (ne n\u00e9cessite pas de session). La plupart de ces solutions ne vous prot\u00e8geront pas int\u00e9gralement.<\/p>\n

Protection CSRF en mode Stateful<\/strong><\/h3>\n

Synchronizer Token Pattern<\/h4>\n

Il s\u2019agit d\u2019ajouter un param\u00e8tre obligatoire correspondant \u00e0 un identifiant d\u2019acc\u00e8s unique et non pr\u00e9dictible, reg\u00e9n\u00e9r\u00e9 pour chaque action utilisateur et par utilisateur (le plus efficace), ou pour chaque session (le moins efficace). Cet identifiant d\u2019acc\u00e8s (ou \u201claisser-passer\u201d) est nomm\u00e9 \u201cjeton CSRF\u201d. Ce m\u00e9canisme doit \u00eatre impl\u00e9ment\u00e9 sur chaque action qui d\u00e9pend de l\u2019utilisateur qui l\u2019ex\u00e9cute (d\u00e9connexion, modification\/suppression de donn\u00e9es en BDD, etc.) et doit avoir une dur\u00e9e de validit\u00e9 limit\u00e9e dans le temps.<\/p>\n

 <\/p>\n

\"Synchronizer<\/a><\/p>\n

Concr\u00e8tement, lorsque l\u2019utilisateur appelle une page, le serveur g\u00e9n\u00e8re un jeton CSRF unique et non pr\u00e9dictible, et le stock en session (ainsi que l\u2019IP publique depuis laquelle le client \u00e0 interrog\u00e9 le serveur ou tout autre discriminant li\u00e9 \u00e0 l\u2019identit\u00e9 de l\u2019internaute. Bien qu’optionnelle, c\u2019est une condition suppl\u00e9mentaire pour accro\u00eetre la s\u00e9curit\u00e9 en s\u2019assurant que le jeton \u00e0 \u00e9t\u00e9 \u00e9mis par la bonne personne).<\/p>\n

– Si c\u2019est un formulaire, le jeton CSRF est ins\u00e9r\u00e9 dans le corps du formulaire (dans un input de type hidden). Lorsque l\u2019utilisateur validera ce formulaire, le jeton CSRF sera renvoy\u00e9 au serveur qui v\u00e9rifiera sa validit\u00e9 et le p\u00e9rimera, un jeton invalide emp\u00eachera le traitement des donn\u00e9es envoy\u00e9es par le formulaire.
\n– Si ce n\u2019est pas un formulaire (acc\u00e8s \u00e0 une page priv\u00e9e par exemple), c\u2019est lors de la g\u00e9n\u00e9ration du lien vers l\u2019action que le jeton sera g\u00e9n\u00e9r\u00e9, stock\u00e9 en session et ajout\u00e9 dans l\u2019URL en tant que param\u00e8tre. Sans jeton, la ressource ne sera donc pas accessible.<\/p>\n

Gr\u00e2ce \u00e0 ce m\u00e9canisme, il devient inutile pour un utilisateur malveillant de forger des liens pour pi\u00e9ger quelqu\u2019un, car le jeton CSRF change et est propre \u00e0 un utilisateur. De plus, cela permet aussi de prot\u00e9ger contre le spam, dans le cas o\u00f9 un robot ne r\u00e9cup\u00e8rerait qu\u2019une seule fois la page (il ne r\u00e9cup\u00e8rerait donc le jeton CSRF qu\u2019une fois et celui-ci sera p\u00e9rim\u00e9 apr\u00e8s la premi\u00e8re tentative de spam).<\/p>\n

Note :<\/span> Autre id\u00e9e int\u00e9ressante pour se pr\u00e9munir contre une grande majorit\u00e9 de robots, il suffirait d\u2019ajouter un champ factice dans chaque formulaire. Ce champ, pour que le formulaire soit valide, doit toujours \u00eatre vide. Il pourrait avoir pour label : \u00ab \u00c0 ne pas remplir \u00bb et serait cach\u00e9 en CSS. Un utilisateur non-averti, avec le CSS activ\u00e9, ne pourrait pas voir ce champ, il ne le remplirait donc pas. Si le CSS est d\u00e9sactiv\u00e9, le label aura un r\u00f4le informatif. Un robot qui analyse la page ne pourrait savoir qu\u2019il s\u2019agit d\u2019un champ factice, il le remplirait donc avant de soumettre le formulaire. Autre avantage en terme d\u2019accessibilit\u00e9 gr\u00e2ce \u00e0 cette solution : les logiciels de lecture de site web sp\u00e9cialis\u00e9s pour les personnes aveugles liraient le label du champ du formulaire permettant de pr\u00e9venir l\u2019utilisateur.<\/p>\n

Double Submit Pattern<\/h4>\n

Toutefois, si notre application est vuln\u00e9rable aux attaques de type XSS, il serait possible pour un attaquant de voler notre cookie de session puis d\u2019ex\u00e9cuter rapidement une action pour \u201cconsommer\u201d le jeton CSRF avant l\u2019utilisateur initial (soit une \u201ctiming-attack\u201d).
\nPour \u00e9viter ce type de d\u00e9rive intervient un dernier concept, celui de \u201cdouble soumission\u201d (ou \u201cdouble submit pattern\u201d) qui consiste \u00e0 complexifier la solution pr\u00e9c\u00e9dente.
\nEn plus d\u2019envoyer le jeton CSRF via un param\u00e8tre dans la requ\u00eate HTTP, il faudra ajouter cette notion dans un cookie avec imp\u00e9rativement l\u2019attribut \u201cHTTPOnly\u201c.
\nAjouter ce dernier attribut permet d\u2019emp\u00eacher Javascript d\u2019acc\u00e9der au cookie et de r\u00e9cup\u00e9rer son contenu (via la directive \u201cdocument.cookie\u201d) pour l\u2019envoyer sur un serveur pirate.
\nCe cookie sera reg\u00e9n\u00e9r\u00e9 \u00e0 chaque fois qu\u2019un jeton sera cr\u00e9\u00e9 et, id\u00e9alement, il devrait s\u2019agir du cookie de session qui contiendra par exemple l\u2019identifiant de session concat\u00e9n\u00e9 au jeton CSRF.<\/p>\n

Pour r\u00e9sumer, pour un utilisateur sp\u00e9cifique et pour chaque action seront g\u00e9n\u00e9r\u00e9s :<\/p>\n