Cet article examine les attaques CSRF, leur fonctionnement et les mesures que vous pouvez prendre pour vous y pr\u00e9parer.<\/p>\n
Consultez notre guide vid\u00e9o pour tout savoir sur les attaques CSRF<\/a><\/strong><\/p>\n Une attaque Cross-Site Request Forgery, \u00e9galement connue sous le nom d’attaque CSRF, incite un utilisateur authentifi\u00e9 \u00e0 effectuer des actions involontaires en soumettant des requ\u00eates malveillantes sans qu’il s’en rende compte.<\/p>\n G\u00e9n\u00e9ralement, une attaque CSRF implique des requ\u00eates de changement d’\u00e9tat car l’attaquant ne re\u00e7oit pas de r\u00e9ponse. Parmi les exemples de ces requ\u00eates, on peut citer la suppression d’un enregistrement, la modification d’un mot de passe<\/a>, l’achat d’un produit ou l’envoi d’un message. Toutes ces actions peuvent se produire \u00e0 l’insu de l’utilisateur.<\/p>\n L’attaquant malveillant utilise g\u00e9n\u00e9ralement l’ing\u00e9nierie sociale pour envoyer \u00e0 un utilisateur peu m\u00e9fiant un lien par l’interm\u00e9diaire d’un tchat ou d’un e-mail.<\/p>\n Lorsque l’utilisateur clique sur le lien, il ex\u00e9cute les commandes d\u00e9finies par l’attaquant.<\/p>\n Par exemple, en cliquant sur un lien, l’utilisateur peut transf\u00e9rer des fonds de son compte. Il peut \u00e9galement modifier l’adresse e-mail d’un utilisateur, l’emp\u00eachant ainsi d’acc\u00e9der \u00e0 nouveau \u00e0 son compte.<\/p>\n Amener l’utilisateur \u00e0 initier une requ\u00eate de changement d’\u00e9tat alors qu’il est connect\u00e9 est la premi\u00e8re \u00e9tape, et la plus cruciale, d’une attaque CSRF. Avec les attaques CSRF, l’attaquant cherche \u00e0 amener un utilisateur authentifi\u00e9 \u00e0 soumettre \u00e0 son insu une requ\u00eate web malveillante \u00e0 un site web ou \u00e0 une application web. Ces requ\u00eates peuvent consister en des cookies, des param\u00e8tres d’URL<\/a> et d’autres types de donn\u00e9es qui semblent normales \u00e0 l’utilisateur.<\/p>\n Pour qu’une attaque CSRF r\u00e9ussisse, les conditions suivantes doivent \u00eatre r\u00e9unies :<\/p>\n La m\u00e9thode la plus courante pour mener \u00e0 bien des attaques CSRF consiste \u00e0 utiliser des cookies dans des applications dont la politique en mati\u00e8re de cookies SameSite est faible. Les navigateurs web incluent les cookies automatiquement<\/a> et souvent de mani\u00e8re anonyme, et ils enregistrent les cookies utilis\u00e9s par un domaine dans toute requ\u00eate web qu’un utilisateur envoie \u00e0 ce domaine.<\/p>\n La politique relative aux cookies SameSite d\u00e9finit la mani\u00e8re dont le navigateur traite les cookies dans les contextes de navigation intersites. S’il est d\u00e9fini sur strict, le cookie n’est pas partag\u00e9 dans les contextes de navigation intersites, ce qui permet d’\u00e9viter les attaques CSRF. Le navigateur attache le cookie dans tous les contextes intersites s’il est d\u00e9fini sur none. L’application est alors vuln\u00e9rable aux attaques CSRF.<\/p>\n Lorsqu’un utilisateur soumet \u00e0 son insu une requ\u00eate malveillante par l’interm\u00e9diaire d’un navigateur web, les cookies enregistr\u00e9s font appara\u00eetre la requ\u00eate comme l\u00e9gitime aux yeux du serveur. Le serveur r\u00e9pond alors \u00e0 la demande en modifiant le compte de l’utilisateur, en changeant l’\u00e9tat de la session ou en renvoyant les donn\u00e9es demand\u00e9es.<\/p>\n Examinons de plus pr\u00e8s deux exemples d’attaques CSRF, l’une avec une requ\u00eate GET et l’autre avec une requ\u00eate POST.<\/p>\n Consid\u00e9rons tout d’abord une requ\u00eate G<\/a> ET utilis\u00e9e par une application web de banque financi\u00e8re, o\u00f9 l’attaque exploite une requ\u00eate GET et la livraison d’un hyperlien.<\/p>\n Supposons que la requ\u00eate GET pour transf\u00e9rer de l’argent ressemble \u00e0 ceci :<\/p>\n Dans la requ\u00eate authentique ci-dessus, l’utilisateur demande \u00e0 transf\u00e9rer 1000 dollars sur un compte \u00e0 l’adresse Bien que cette demande soit explicite, simple et pratique, elle expose le titulaire du compte \u00e0 une attaque CSRF. En effet, la demande ne requiert pas de d\u00e9tails qu’un attaquant pourrait ne pas conna\u00eetre. Ainsi, pour lancer une attaque, un pirate n’aurait qu’\u00e0 modifier les param\u00e8tres de cette requ\u00eate (le montant et le num\u00e9ro de compte) pour cr\u00e9er une fausse requ\u00eate ex\u00e9cutable.<\/p>\n La demande malveillante serait efficace pour tous les utilisateurs de la banque tant qu’ils ont des sessions en cours g\u00e9r\u00e9es par des cookies.<\/p>\n Voici \u00e0 quoi ressemblerait la fausse demande de transfert de 500 dollars vers le compte d’un pirate (ici, le num\u00e9ro Une fois cette \u00e9tape franchie, le pirate doit trouver un moyen de tromper l’utilisateur pour qu’il envoie cette requ\u00eate alors qu’il est connect\u00e9 \u00e0 son application de banque en ligne. L’un des moyens d’y parvenir consiste \u00e0 cr\u00e9er un lien hypertexte inoffensif qui attire l’attention de l’utilisateur. Le lien peut ressembler \u00e0 ceci :<\/p>\n \u00c9tant donn\u00e9 que le pirate a trouv\u00e9 les adresses \u00e9lectroniques correctes<\/a> de ses cibles, il peut envoyer ce lien par courrier \u00e9lectronique \u00e0 de nombreux clients de la banque. Ceux qui cliqueront sur le lien alors qu’ils sont connect\u00e9s d\u00e9clencheront la requ\u00eate d’envoyer au pirate 500 dollars \u00e0 partir du compte connect\u00e9.<\/p>\n Voyons comment la m\u00eame institution financi\u00e8re pourrait subir un CSRF si elle n’acceptait que des requ\u00eates POST<\/a>. Dans ce cas, la livraison de l’hyperlien utilis\u00e9e dans l’exemple de la requ\u00eate GET ne fonctionnerait pas. Par cons\u00e9quent, pour qu’une attaque CSRF r\u00e9ussisse, il faudrait que l’attaquant cr\u00e9e un formulaire HTML. La demande authentique d’envoi de 1000 dollars pour un produit achet\u00e9 ressemblerait \u00e0 ceci :<\/p>\n Cette requ\u00eate POST n\u00e9cessite un cookie pour d\u00e9terminer l’identit\u00e9 de l’utilisateur, le montant qu’il souhaite envoyer et le compte qu’il souhaite envoyer. Les attaquants peuvent modifier cette requ\u00eate pour effectuer une attaque CSRF.<\/p>\n L’attaquant n’a qu’\u00e0 ajouter un cookie authentique \u00e0 une requ\u00eate falsifi\u00e9e pour que le serveur traite le transfert. Pour cela, il peut cr\u00e9er un lien hypertexte d’apparence inoffensive qui conduit l’utilisateur \u00e0 une page web de d\u00e9clenchement ressemblant \u00e0 celle-ci :<\/p>\n Nous avons d\u00e9j\u00e0 d\u00e9fini le montant et les param\u00e8tres du compte dans le formulaire ci-dessus. Lorsqu’un utilisateur authentifi\u00e9 visite la page, le navigateur ajoute le cookie de session avant de transmettre la demande au serveur. Le serveur transf\u00e8re alors 500 dollars sur le compte du pirate.<\/p>\n Il existe plusieurs m\u00e9thodes pour pr\u00e9venir et att\u00e9nuer consid\u00e9rablement les attaques CSRF potentielles sur votre site web ou votre application web :<\/p>\n Un site web s\u00e9curis\u00e9 contre les attaques CSRF attribue \u00e0 chaque session un jeton unique qu’il partage avec le serveur et le navigateur<\/a> du client. Lorsqu’un navigateur envoie une requ\u00eate sensible, le serveur s’attend \u00e0 ce qu’elle contienne le jeton CSRF attribu\u00e9. S’il s’agit d’un jeton erron\u00e9, le serveur l’abandonne. Pour des raisons de s\u00e9curit\u00e9, le jeton CSRF n’est pas stock\u00e9 dans les cookies de session du navigateur du client.<\/p>\n Bien que les jetons CSRF constituent une excellente mesure de s\u00e9curit\u00e9, cette m\u00e9thode n’est pas \u00e0 l’abri des attaques. Voici quelques-unes des vuln\u00e9rabilit\u00e9s qui accompagnent les jetons CSRF :<\/p>\n Un attaquant n’a qu’\u00e0 retirer le jeton et \u00e0 l’envoyer comme ceci pour ex\u00e9cuter l’attaque :<\/p>\n Un attaquant peut se connecter \u00e0 une application en utilisant son compte pour obtenir un jeton, tel que :<\/p>\n Et comme les jetons sont mis en commun, l’attaquant peut copier et utiliser ce m\u00eame jeton pour se connecter \u00e0 un autre compte utilisateur, car vous l’utiliserez \u00e0 nouveau :<\/p>\n Ainsi, un pirate peut se connecter \u00e0 une application en utilisant son compte et ouvrir le fichier cookie pour voir ce qui suit :<\/p>\n Il peut ensuite utiliser ces informations pour cr\u00e9er un autre cookie afin de mener \u00e0 bien l’attaque<\/p>\n Une autre strat\u00e9gie de pr\u00e9vention des attaques CSRF consiste \u00e0 utiliser l’en-t\u00eate referrer. Dans le protocole HTTP, les en-t\u00eates de r\u00e9f\u00e9rence indiquent l’origine des requ\u00eates. Ils sont g\u00e9n\u00e9ralement utilis\u00e9s \u00e0 des fins d’analyse<\/a>, d’optimisation et de journalisation.<\/p>\n Vous pouvez \u00e9galement activer la v\u00e9rification des en-t\u00eates de r\u00e9f\u00e9rence c\u00f4t\u00e9 serveur pour emp\u00eacher les attaques CSRF. Le serveur v\u00e9rifie l’origine de la source de la demande et d\u00e9termine l’origine de la cible de la requ\u00eate. S’ils correspondent, la requ\u00eate est autoris\u00e9e. En cas de non-concordance, le serveur rejette la requ\u00eate.<\/p>\n L’utilisation d’en-t\u00eates de r\u00e9f\u00e9rence est beaucoup plus facile que l’utilisation de jetons parce qu’elle ne n\u00e9cessite pas l’identification individuelle de l’utilisateur.<\/p>\n Tout comme les jetons CSRF, les en-t\u00eates r\u00e9f\u00e9rents pr\u00e9sentent des vuln\u00e9rabilit\u00e9s importantes.<\/p>\n Tout d’abord, les en-t\u00eates de r\u00e9f\u00e9rence ne sont pas obligatoires et certains sites envoient des requ\u00eates sans en avoir. Si le CSRF n’a pas de politique pour traiter les requ\u00eates sans en-t\u00eate, les attaquants peuvent utiliser les requ\u00eates sans en-t\u00eate pour ex\u00e9cuter des attaques par changement d’\u00e9tat.<\/p>\n En outre, cette m\u00e9thode est devenue moins efficace avec l’introduction r\u00e9cente de la politique de r\u00e9f\u00e9rence (referrer policy)<\/a>. Cette sp\u00e9cification emp\u00eache les fuites d’URL vers d’autres domaines, en donnant aux utilisateurs plus de contr\u00f4le sur les informations contenues dans l’en-t\u00eate referrer. Ils peuvent choisir d’exposer une partie des informations de l’en-t\u00eate du r\u00e9f\u00e9rent ou de les d\u00e9sactiver en ajoutant une balise de m\u00e9tadonn\u00e9es sur la page HTML, comme indiqu\u00e9 ci-dessous :<\/p>\n Le code ci-dessus supprime l’en-t\u00eate referrer pour toutes les requ\u00eates provenant de cette page. Ce faisant, il est difficile pour les applications qui s’appuient sur les en-t\u00eates de r\u00e9f\u00e9rence de pr\u00e9venir les attaques CSRF \u00e0 partir d’une telle page.<\/p>\n Outre l’utilisation de l’en-t\u00eate referrer et des jetons CSRF, il existe une troisi\u00e8me option, bien plus simple : choisir un service d’h\u00e9bergement s\u00e9curis\u00e9 comme Kinsta<\/a> pour vos sites et applications web constitue une barri\u00e8re bien plus solide et s\u00fbre entre les attaquants et vos utilisateurs.<\/p>\n En plus des fonctions de s\u00e9curit\u00e9 essentielles telles que les sauvegardes automatiques<\/a>, l’authentification \u00e0 deux facteurs<\/a> et les protocoles SFTP et SSH<\/a>, l’int\u00e9gration de Cloudflare de Kinsta<\/a> offre une protection au niveau de l’entreprise avec une protection bas\u00e9e sur l’IP et un pare-feu.<\/p>\n Plus pr\u00e9cis\u00e9ment, Kinsta dispose actuellement d’environ 60 r\u00e8gles de pare-feu personnalis\u00e9es pour aider \u00e0 pr\u00e9venir les attaques malveillantes et \u00e0 traiter les graves vuln\u00e9rabilit\u00e9s non authentifi\u00e9es dans les extensions et les th\u00e8mes, y compris des r\u00e8gles sp\u00e9cifiques qui recherchent les vuln\u00e9rabilit\u00e9s CSRF.<\/p>\n La falsification des requ\u00eates intersites (CSRF) est une attaque qui incite les utilisateurs authentifi\u00e9s \u00e0 initier des requ\u00eates de changement d’\u00e9tat de mani\u00e8re non intentionnelle. Ces attaques ciblent les applications qui ne peuvent pas faire la diff\u00e9rence entre les requ\u00eates de changement d’\u00e9tat valides et les requ\u00eates falsifi\u00e9es.<\/p>\n L’attaque CSRF ne peut r\u00e9ussir que sur des applications qui s’appuient sur des cookies de session pour identifier les utilisateurs connect\u00e9s et dont la politique en mati\u00e8re de cookies SameSite est faible. Elles ont \u00e9galement besoin d’un serveur qui accepte les requ\u00eates ne contenant pas de param\u00e8tres inconnus tels que des mots de passe. Les pirates peuvent envoyer des attaques malveillantes en utilisant GET ou POST.<\/p>\n Bien que l’utilisation de jetons CSRF ou la v\u00e9rification de l’en-t\u00eate referrer puissent emp\u00eacher certaines attaques CSRF, ces deux mesures pr\u00e9sentent des vuln\u00e9rabilit\u00e9s potentielles qui peuvent rendre vos mesures pr\u00e9ventives inutiles si vous n’\u00eates pas prudent.<\/p>\nQu’est-ce qu’une attaque CSRF ?<\/h2>\n
![\"Comment](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/CSRF-Attack-Okta.png\")
Comment fonctionne une attaque CSRF ?<\/h2>\n
\n
CSRF pour une requ\u00eate GET<\/h2>\n
GET https:\/\/xymbank.com\/online\/transfer?amount=1000&accountNumber=547895 HTTP\/1.1<\/code><\/pre>\n547895<\/code> en guise de paiement pour des produits achet\u00e9s.<\/p>\n654585<\/code>). Notez que l’exemple ci-dessous est une version tr\u00e8s simplifi\u00e9e des \u00e9tapes d’une attaque CSRF.<\/p>\nGET https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585 HTTP\/1.1<\/code><\/pre>\n<a\nhref=\"https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585\">Click here to get more information<\/a>.<\/code><\/pre>\nCSRF pour une requ\u00eate POST<\/h2>\n
POST \/online\/transfer HTTP\/1.1\nHost: xymbank.com\nContent-Type: application\/x-www-form-urlencoded\nCookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg\namount=1000\naccount=547895<\/code><\/pre>\n<html>\n<body>\n<form action=\"https:\/\/xymbank.com\/online\/transfer\" method=\"POST\">\n<input type=\"hidden\" name=\"amount\" value=\"500\"\/>\n<input type=\"hidden\" name=\"account\" value=\"654585\" \/>\n<\/form>\n<script>\ndocument.forms[0].submit();\n<\/script>\n<\/body>\n<\/html><\/code><\/pre>\n3 fa\u00e7ons d’att\u00e9nuer les attaques CSRF<\/h2>\n
\n
Comment pr\u00e9venir les attaques CSRF \u00e0 l’aide de jetons CSRF<\/h2>\n
Vuln\u00e9rabilit\u00e9s potentielles des jetons CSRF<\/h3>\n
\n
POST \/change_password\nPOST body:\npassword=pass123&csrf_token=93j9d8eckke20d433<\/code><\/pre>\nPOST \/change_password\nPOST body:\npassword=pass123<\/code><\/pre>\n\n
[application_url].com?csrf_token=93j9d8eckke20d433<\/code><\/pre>\n\n
Csrf_token:93j9d8eckke20d433<\/code><\/pre>\n\n
Comment pr\u00e9venir les attaques CSRF \u00e0 l’aide de l’en-t\u00eate Referrer ?<\/h2>\n
Vuln\u00e9rabilit\u00e9s potentielles de l’en-t\u00eate Referrer<\/h3>\n
<meta name=\"referrer\" content=\"no-referrer\"><\/code><\/pre>\nComment Kinsta se prot\u00e8ge contre les attaques CSRF<\/h2>\n
R\u00e9sum\u00e9<\/h2>\n