Comprendre les attaques CSRF et verrouiller les vulnérabilités CSRF

Les vulnérabilités Web sont endémiques et en constante augmentation. Maintenir la sécurité et la confidentialité de vos utilisateurs est plus important que jamais. Ne pas traiter les vulnérabilités Web peut entraîner une réputation ruinée et de lourdes amendes de la part des régulateurs, et vous perdrez également la confiance de vos utilisateurs.

Les sites Web et les applications Web sont vulnérables aux logiciels malveillants, aux spams et à d'autres attaques. Cet article se concentre sur l'un de ces vecteurs d'attaque : les attaques par falsification de requête intersite (CSRF). Les attaques CSRF sont particulièrement troublantes car elles peuvent se produire à l'insu de l'utilisateur. Ils sont également difficiles à détecter pour un développeur ou un propriétaire de site Web, car les demandes malveillantes semblent très similaires aux demandes authentiques.

Cet article explore une attaque CSRF, son fonctionnement et les étapes à suivre pour s'y préparer.

Qu'est-ce qu'une attaque CSRF ?

Une attaque Cross-Site Request Forgery, également connue sous le nom d'attaque CSRF, incite un utilisateur authentifié à effectuer des actions involontaires en soumettant des demandes malveillantes sans qu'il s'en rende compte.

En règle générale, une attaque CSRF implique des demandes de changement d'état car l'attaquant ne reçoit pas de réponse. Des exemples de telles demandes incluent la suppression d'un enregistrement, la modification d'un mot de passe, l'achat d'un produit ou l'envoi d'un message. Ceux-ci peuvent tous se produire à l'insu de l'utilisateur.

L'attaquant malveillant utilise généralement l'ingénierie sociale pour envoyer un lien à un utilisateur peu méfiant par chat ou par e-mail.

Lorsque l'utilisateur clique sur le lien, il exécute les commandes définies par l'attaquant.

Par exemple, cliquer sur un lien peut transférer des fonds depuis le compte d'un utilisateur. Ou, il peut modifier l'adresse e-mail d'un utilisateur, l'empêchant de retrouver l'accès au compte.

Comment fonctionne une attaque CSRF ?

Faire en sorte que l'utilisateur lance une demande de changement d'état alors qu'il est connecté est la première et la plus cruciale des étapes d'une attaque CSRF. Avec les attaques CSRF, l'attaquant vise à amener un utilisateur authentifié à soumettre sans le savoir une requête Web malveillante à un site Web ou à une application Web. Ces demandes peuvent consister en des cookies, des paramètres d'URL et d'autres types de données qui semblent normaux à l'utilisateur.

Pour qu'une attaque CSRF réussisse, les conditions suivantes doivent être remplies :

• Un utilisateur authentifié doit être connecté à une application Web qui utilise des cookies pour la gestion des sessions.
• Un attaquant doit créer une requête falsifiée de changement d'état.
• Les demandes authentiques gérées par le serveur cible ne doivent pas contenir de paramètres imprévisibles. Par exemple, la demande ne devrait pas attendre un mot de passe comme paramètre à des fins de vérification avant de lancer la demande de changement d'état.

La méthode la plus courante pour effectuer des attaques CSRF consiste à utiliser des cookies dans des applications avec une politique de cookies SameSite faible. Les navigateurs Web incluent des cookies automatiquement et souvent de manière anonyme, et ils enregistrent les cookies utilisés par un domaine dans toute requête Web qu'un utilisateur envoie à ce domaine.

La politique de cookie de SameSite définit la manière dont le navigateur dans les contextes de navigation intersites traite le cookie. S'il est défini sur strict, le cookie n'est pas partagé dans les contextes de navigation intersites, ce qui empêche les attaques CSRF. Le navigateur attache le cookie dans tous les contextes intersites s'il est défini sur aucun. Cela rend l'application vulnérable aux attaques CSRF.

Lorsqu'un utilisateur soumet sans le savoir une demande malveillante via un navigateur Web, les cookies enregistrés font que la demande semble légitime au serveur. Le serveur répond ensuite à la demande en modifiant le compte de l'utilisateur, en modifiant l'état de la session ou en renvoyant les données demandées.

Examinons de plus près deux exemples de voies d'attaque CSRF, l'une avec une requête GET et l'autre avec une requête POST.

CSRF pour une requête GET

Considérons tout d'abord une requête GET utilisée par une application Web de banque financière, où l'attaque exploite une requête GET et la livraison d'un lien hypertexte.

Supposons que la requête GET de transfert d'argent ressemble à ceci :

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

Dans la demande authentique ci-dessus, l'utilisateur demande de transférer 1 000 $ sur un compte avec 547895 en paiement des produits achetés.

Bien que cette demande soit explicite, simple et pratique, elle expose le titulaire du compte à une attaque CSRF. En effet, la demande ne nécessite pas de détails qu'un attaquant peut ne pas connaître. Ainsi, pour lancer une attaque, un attaquant n'aurait qu'à modifier les paramètres de cette requête (le montant et le numéro de compte) pour créer une requête falsifiée exécutable.

La demande malveillante serait efficace sur tous les utilisateurs de la banque tant qu'ils ont des sessions gérées par des cookies en cours.

Voici à quoi ressemblerait la fausse demande de transfert de 500 $ sur le compte d'un pirate (ici, le numéro 654585 ). Notez que l'exemple ci-dessous est une version très simplifiée des étapes impliquées dans une attaque CSRF pour une explication.

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

Une fois cette opération terminée, l'attaquant doit trouver un moyen d'inciter l'utilisateur à envoyer cette demande alors qu'il est connecté à son application bancaire en ligne. L'une des façons d'y parvenir est de créer un lien hypertexte inoffensif qui attire l'attention de l'utilisateur. Le lien peut ressembler à ceci :

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Étant donné que l'attaquant a trouvé les adresses e-mail correctes de ses cibles, il peut les envoyer par e-mail à de nombreux clients bancaires. Ceux qui cliquent sur le lien alors qu'ils sont connectés déclenchent la demande d'envoi de 500 $ à l'attaquant à partir du compte connecté.

CSRF pour une requête POST

Voyons comment la même institution financière connaîtrait un CSRF si elle n'acceptait que les demandes POST. Dans ce cas, la livraison de lien hypertexte utilisée dans l'exemple de requête GET ne fonctionnerait pas. Par conséquent, une attaque CSRF réussie nécessiterait qu'un attaquant crée un formulaire HTML. La véritable demande d'envoi de 1 000 $ pour un produit acheté ressemblerait à ceci :

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

Cette requête POST nécessite un cookie pour déterminer l'identité de l'utilisateur, le montant qu'il souhaite envoyer et le compte qu'il souhaite envoyer. Les attaquants peuvent modifier cette demande pour effectuer une attaque CSRF.

L'attaquant doit uniquement ajouter un cookie authentique à une requête falsifiée pour que le serveur traite le transfert. Ils peuvent le faire en créant un lien hypertexte inoffensif qui dirige l'utilisateur vers une page Web de déclenchement qui ressemble à ceci :

 <html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

Nous avons déjà défini le montant et les paramètres du compte dans le formulaire ci-dessus. Une fois qu'un utilisateur authentifié visite la page, le navigateur ajoute le cookie de session avant de transmettre la demande au serveur. Le serveur transmet ensuite 500 $ au compte du pirate.

3 façons de réduire les attaques CSRF

Il existe plusieurs méthodes pour prévenir et atténuer considérablement les attaques CSRF potentielles sur votre site Web ou votre application Web, notamment :

• Utiliser des jetons CSRF
• Utilisation de l'en-tête de référence
• Choisir une solution d'hébergement axée sur la sécurité, comme Kinsta

Comment prévenir les attaques CSRF à l'aide de jetons CSRF

Un site Web sécurisé CSRF attribue à chaque session un jeton unique et le partage avec le côté serveur et le navigateur client. Chaque fois qu'un navigateur envoie une requête sensible, le serveur s'attend à ce qu'elle contienne le jeton CSRF attribué. S'il a le mauvais jeton, le serveur le supprime. Le jeton CSRF n'est pas stocké dans les cookies de session sur le navigateur du client pour des raisons de sécurité.

Vulnérabilités potentielles des jetons CSRF

Bien que les jetons CSRF soient une excellente mesure de sécurité, cette méthode n'est pas à l'épreuve des attaques. Certaines des vulnérabilités accompagnant les jetons CSRF incluent :

• Contournement de la validation — Certaines applications ignorent l'étape de vérification si elles ne trouvent pas de jeton. Si un attaquant accède au code contenant un jeton, il peut supprimer ce jeton et exécuter avec succès une attaque CSRF. Ainsi, si une requête valide adressée à un serveur ressemble à ceci :

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

Un attaquant n'a qu'à retirer le jeton et l'envoyer comme ceci pour exécuter l'attaque :

 POST /change_password POST body: password=pass123

• Jetons groupés — Certaines applications maintiennent un pool de jetons pour valider les sessions utilisateur au lieu de désigner un jeton spécifique à une session. Un attaquant n'a besoin que d'obtenir l'un des jetons déjà présents dans le pool pour se faire passer pour l'un des utilisateurs du site.

Un attaquant peut se connecter à une application en utilisant son compte pour obtenir un jeton, tel que :

 [application_url].com?csrf_token=93j9d8eckke20d433

Et puisque les jetons sont regroupés, l'attaquant peut copier et utiliser ce même jeton pour se connecter à un compte d'utilisateur différent, car vous l'utiliserez à nouveau :

• Les CSRF peuvent être copiés par jeton dans le cookie — Certaines applications copient les paramètres liés à un jeton dans le cookie d'un utilisateur. Si un attaquant accède à un tel cookie, il peut facilement créer un autre cookie, le placer dans un navigateur et exécuter une attaque CSRF.

Ainsi, un attaquant peut se connecter à une application en utilisant son compte et ouvrir le fichier cookie pour voir ce qui suit :

 Csrf_token:93j9d8eckke20d433

Ils peuvent ensuite utiliser ces informations pour créer un autre cookie afin de compléter l'attaque

• Jetons non valides — Certaines applications ne font pas correspondre les jetons CSRF à une session utilisateur. Dans de tels cas, un attaquant peut véritablement se connecter à une session, obtenir un jeton CSRF similaire à ceux ci-dessus et l'utiliser pour orchestrer une attaque CSRF sur la session d'une victime.

Comment empêcher les attaques CSRF avec l'en-tête Referrer

Une autre stratégie pour empêcher les attaques CSRF consiste à utiliser l'en-tête de référence. En HTTP, les en-têtes de référence indiquent l'origine des requêtes. Ils sont généralement utilisés pour effectuer des analyses, des optimisations et des journaux.

Vous pouvez également activer la vérification des en-têtes de référence côté serveur pour empêcher les attaques CSRF. Le côté serveur vérifie l'origine source de la demande et détermine l'origine cible de la demande. S'ils correspondent, la demande est autorisée. S'il y a une non-concordance, le serveur abandonne la demande.

L'utilisation d'en-têtes de référence est beaucoup plus simple que l'utilisation de jetons, car elle ne nécessite pas d'identification individuelle de l'utilisateur.

Vulnérabilités potentielles de l'en-tête Referrer

Comme les jetons CSRF, les en-têtes de référence présentent des vulnérabilités importantes.

Premièrement, les en-têtes de référence ne sont pas obligatoires et certains sites enverront des requêtes sans eux. Si le CSRF n'a pas la politique de gérer les requêtes sans en-tête, les attaquants peuvent utiliser des requêtes sans en-tête pour exécuter des attaques de changement d'état.

De plus, cette méthode est devenue moins efficace avec l'introduction récente de la politique de référence. Cette spécification empêche la fuite d'URL vers d'autres domaines, donnant aux utilisateurs plus de contrôle sur les informations contenues dans l'en-tête du référent. Ils peuvent choisir d'exposer une partie des informations d'en-tête du référent ou de les désactiver en ajoutant une balise de métadonnées sur la page HTML, comme indiqué ci-dessous :

 <meta name="referrer" content="no-referrer">

Le code ci-dessus supprime l'en-tête de référence pour toutes les demandes de cette page. Cela complique la tâche des applications qui s'appuient sur des en-têtes de référence pour empêcher les attaques CSRF à partir d'une telle page.

Comment Kinsta se protège contre les attaques CSRF

En plus d'utiliser l'en-tête de référence et les jetons CSRF, il existe une troisième option bien plus simple : choisir un service d'hébergement sécurisé comme Kinsta pour vos sites Web et applications Web fournit une barrière beaucoup plus solide et plus sécurisée entre les attaquants et vos utilisateurs.

En plus des fonctionnalités de sécurité critiques telles que les sauvegardes automatiques, l'authentification à deux facteurs et les protocoles SFTP sur SSH, l'intégration Cloudflare de Kinsta offre une protection de niveau entreprise avec une protection basée sur IP et un pare-feu.

Plus précisément, Kinsta dispose actuellement d'environ 60 règles de pare-feu personnalisées pour aider à prévenir les attaques malveillantes et à gérer les vulnérabilités graves non authentifiées dans les plugins et les thèmes, y compris celles spécifiques qui recherchent les vulnérabilités CSRF.

Sommaire

La falsification de requêtes intersites (CSRF) est une attaque qui incite les utilisateurs authentifiés à lancer involontairement des requêtes de changement d'état. Ils ciblent les applications qui ne peuvent pas faire la différence entre les requêtes de changement d'état valides et falsifiées.

CSRF ne peut réussir que sur des applications qui s'appuient sur des cookies de session pour identifier les utilisateurs connectés et qui ont une politique de cookies SameSite faible. Ils ont également besoin d'un serveur qui accepte les requêtes ne contenant pas de paramètres inconnus tels que des mots de passe. Les pirates peuvent envoyer des attaques malveillantes en utilisant GET ou POST.

Bien que l'utilisation de jetons CSRF ou l'application de la vérification de l'en-tête du référent puisse empêcher certaines attaques CSRF, les deux mesures présentent des vulnérabilités potentielles qui peuvent rendre vos mesures préventives inutiles si vous ne faites pas attention.

La migration vers une plate-forme d'hébergement sécurisée comme Kinsta sécurise vos sites Web ou vos applications Web contre les attaques CSRF. De plus, l'intégration de Kinsta avec Cloudflare empêche les attaques CSRF spécifiques.