Qu'est-ce que la falsification de requête intersite (CSRF) ?

Publié: 2023-04-12

Les vulnérabilités CSRF ou XSRF (Cross-Site Request Forgery) sont rarement élevées ou critiques dans leurs cotes de gravité. Cependant, ils peuvent encore faire beaucoup de mal. Ils ont été la deuxième vulnérabilité WordPress la plus courante ces dernières années après les vulnérabilités Cross-Site Scripting (XSS). Vous comprendrez comment mieux protéger votre site Web si vous savez ce qu'est une vulnérabilité CSRF et comment les attaquants les exploitent couramment.

Contourner la politique de même origine

Une vulnérabilité CSRF permet à un attaquant de contourner une fonctionnalité standard du navigateur appelée la politique de même origine. Tous les navigateurs Web suivent cette règle pour empêcher le type d'interférence que les CSRF permettent. Normalement, lorsque vous chargez une page Web, votre navigateur n'interagit qu'avec un domaine ou sous-domaine, à l'exception de toute exception autorisée. Et il n'acceptera que le contenu sur un protocole, HTTP ou HTTPS (pas les deux), sans vous avertir qu'il y a un problème. Si des individus malveillants contournent la politique de même origine, ils peuvent également vous inciter à cliquer sur des liens qui effectuent des actions indésirables en interagissant de manière inattendue avec un autre site.

Si votre site WordPress a été exploité via une vulnérabilité CSRF, vous et vos visiteurs pourriez être victimes de phishing, de détournement de clics et pire encore. Heureusement, des mises à jour opportunes, une authentification forte et des clés d'accès pour une expérience de connexion sans mot de passe renforceront votre site WordPress et annuleront de nombreux exploits, y compris les tentatives CSRF.

Visuellement, vous auriez peu ou pas d'indices que vous interagissez avec un autre site de manière indésirable. Le détournement de clic fonctionne comme ceci. Si votre site WordPress a été exploité via une vulnérabilité CSRF, vous et vos visiteurs pourriez être victimes de phishing, de détournement de clics et pire encore.

Dans ce guide, nous allons approfondir les détails des falsifications de requêtes intersites. Nous allons examiner un exemple spécifique d'une vulnérabilité CSRF afin que vous compreniez comment ils fonctionnent. Ensuite, nous vous montrerons ce que vous pouvez faire pour empêcher l'apparition de vulnérabilités CSRF sur votre site. Nous suggérerons également des moyens d'annuler ou de limiter les dommages qu'un exploit CSRF réussi peut causer en renforçant votre site contre ces types d'attaques et d'autres.

Nous allons jeter un coup d'oeil.

Comment une attaque Cross-Site Request Forgery (CSRF) affecte-t-elle votre site WordPress ?

Lorsqu'une attaque CSRF réussit, ses victimes autorisent involontairement une action nuisible, comme une mise à jour de leurs identifiants de connexion. Ils pourraient être amenés à autoriser un attaquant à prendre le contrôle de leur compte d'utilisateur. Pire encore, une victime d'un exploit CSRF pourrait laisser les attaquants initier des transferts financiers en son nom.

Si un plugin sur votre site WordPress contient une vulnérabilité CSRF, un attaquant pourrait être en mesure de détourner certains comptes d'utilisateurs. Ce serait l'un des pires scénarios. Si un compte volé a un rôle administratif dans WordPress ou si l'utilisateur réutilise son mot de passe sur d'autres sites, les dommages pourraient être importants.

Falsification de requêtes intersites

Comment fonctionne une attaque CSRF ?

Trois conditions différentes doivent exister pour qu'un pirate informatique fasse fonctionner une attaque CSRF. Si vous les comprenez de manière générale, vous aurez une bonne compréhension de certains principes fondamentaux de la sécurité Web.

1. Gestion de session basée sur les cookies

Comme d'autres applications sans état, WordPress s'appuie sur les cookies de session pour identifier les utilisateurs. Dans des conditions de sécurité faibles ou compromises, un attaquant peut être en mesure de créer de faux cookies de session ou de manipuler un utilisateur connecté pour effectuer des actions indésirables. WordPress acceptera les demandes falsifiées et manipulées qui proviennent ou semblent provenir d'un utilisateur connecté.

Alors que les exploits CSRF ciblent souvent la gestion de session basée sur les cookies, ce n'est pas leur seule cible. Les attaques CSRF peuvent être efficaces contre toute application qui ajoute automatiquement les informations d'identification de l'utilisateur aux demandes. L'authentification basée sur les certificats et l'authentification HTTP de base sont également sensibles aux vulnérabilités CSRF pour cette raison.

2. Une action pertinente peut être ciblée

Il doit y avoir une action dans l'application ciblée que les victimes peuvent être amenées à prendre. Il peut s'agir d'une action privilégiée telle que la modification des autorisations des utilisateurs. Cela peut être lié à des données spécifiques à l'utilisateur, comme la mise à jour du mot de passe d'un utilisateur. Ce sont des actions courantes dans toutes les applications Web, y compris WordPress. Ils ont une valeur en tant que cibles pour les pirates, car ils pourraient leur ouvrir la voie pour voler des comptes d'utilisateurs et creuser plus profondément pour trouver des moyens de se livrer au vol, à la fraude ou à d'autres activités malveillantes.

3. Aucun paramètre de demande imprévisible

Les demandes qui effectuent l'action ciblée doivent être connues ou prévisibles. Si les requêtes ciblées n'ont pas besoin de contenir des paramètres dont les valeurs ne peuvent pas être déterminées ou devinées par l'attaquant, elles sont plus vulnérables à la manipulation.

Par exemple, si une demande de changement de mot de passe valide doit inclure le mot de passe existant, elle est sécurisée, tant qu'un attaquant ne connaît pas le mot de passe. Les jetons CSRF et les cookies SameSite ajoutent des obstacles supplémentaires aux attaquants lorsque les développeurs les utilisent pour sécuriser leur code. Mais parfois, les développeurs n'implémentent pas ces méthodes de sécurité correctement ou pas du tout. (C'est pourquoi une authentification utilisateur forte et sans mot de passe est précieuse.)

Exploitation d'une vulnérabilité CSRF pour modifier les e-mails de compte utilisateur - Un exemple

Voici un exemple plus approfondi. Cela ne fonctionnera pas réellement, mais cela illustre les principaux concepts en jeu pour un exploit CSRF efficace.

Envisagez une demande de changement d'e-mail. Lorsqu'un utilisateur effectue cette action, il envoie une requête HTTP qui ressemble à ceci au serveur Web qui la reçoit :

 POST /test HTTP/1.1 Host: yourwebsite.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

Pourquoi ça marche

Cela remplit les conditions requises pour CSRF si/parce que :

  • Le site/l'application ciblé utilise un cookie de session pour identifier l'utilisateur qui a émis la demande, et il n'y a pas d'autres jetons ou mécanismes en place pour suivre les sessions des utilisateurs. C'est pourquoi les développeurs doivent utiliser des jetons CSRF et/ou des cookies SameSite.
  • Changer l'adresse e-mail d'un utilisateur est une action pertinente dans l'intérêt d'un attaquant. Tout à fait! Si vous pouvez remplacer l'adresse e-mail d'un utilisateur par une adresse que vous contrôlez, vous pouvez prendre le contrôle total de son compte.
  • L'attaquant connaît les paramètres de requête dont il a besoin pour modifier l'adresse e-mail d'un utilisateur et peut générer des valeurs valides pour eux. Ces paramètres ne sont pas secrets et il n'est pas difficile de déterminer quelles adresses e-mail de nombreuses personnes utilisent pour leurs comptes en ligne. Le cookie de session est plus délicat.

Comment un attaquant pourrait voler des cookies de session

Le principal obstacle de l'attaquant consiste à déterminer les valeurs réelles des paramètres qui accéderont au compte d'un utilisateur particulier. Ils peuvent le faire en créant une page Web destinée aux utilisateurs du site ciblé. Ce site trompeur peut contenir des liens ou des boutons qui semblent avoir un but légitime, comme demander des cadeaux gratuits. En réalité, si vous cliquez sur ces liens ou boutons, la seule personne qui reçoit gratuitement des friandises est l'attaquant.

Lorsque vous cliquez sur ces liens frauduleux, ils feront une demande de changement d'adresse au site ciblé et vulnérable au CSRF. Si vous êtes connecté à ce site, la demande sera valide. Votre compte a été volé — vous avez remis vos clés.

Les utilisateurs d'un site WordPress qui restent connectés ont un cookie de session actif dans leur navigateur qui persiste même lorsqu'ils se trouvent sur un autre site. Leur navigateur inclura automatiquement ce cookie de session dans une requête falsifiée. WordPress peut considérer cela comme une demande de changement d'adresse parfaitement valide - même si elle provient d'un autre site et que l'utilisateur n'a aucune idée de ce qu'il fait.

En supposant qu'aucune autre mesure de sécurité n'est en place, comme l'attribut de cookie SameSite, le site cible vulnérable traitera une demande falsifiée de la même manière qu'une demande valide. Si le site Web ciblé n'applique pas une étape de confirmation de changement d'adresse, ou si l'attaquant a un moyen de le contourner, l'attaquant réussira à changer l'adresse de l'utilisateur en celle qu'il choisit.

Comment une attaque CSRF est transmise à un site Web vulnérable

Les mécanismes de diffusion des attaques CSRF et des attaques de type Reflected Cross-Site Scripting (Reflected XSS) sont similaires.

Dans la plupart des cas, les attaquants placeront leur code malveillant sur un site trompeur qu'ils contrôlent. Il peut s'agir d'un site légitime qu'ils ont déjà compromis, c'est pourquoi Google maintient une liste de sites trompeurs. Tous les navigateurs avertiront leurs utilisateurs si vous êtes sur cette liste ! C'est pourquoi iThemes Security vérifie chaque jour pour s'assurer que votre site n'est pas devenu un outil de piratage.

Faire en sorte que des victimes potentielles visitent un site Web trompeur est simplement une question de médias sociaux de base et de marketing par e-mail. Parfois, le code malveillant est simplement placé sur un site populaire dans une zone active.

Un attaquant peut même ne pas avoir besoin d'un site Web pour attirer ses victimes. Certains exploits CSRF simples utilisent la méthode GET. C'est ce que fait votre navigateur lorsque vous cliquez sur un lien ou saisissez une URL dans la barre d'adresse. Il fait une requête GET en utilisant l'URL dans le lien ou que vous fournissez. Parfois, une attaque CSRF peut être entièrement exécutée avec une seule requête GET à un site Web vulnérable. Dans de telles situations, l'attaquant n'a peut-être pas besoin d'utiliser un site Web trompeur. Ils peuvent simplement fournir directement à leurs victimes une URL malveillante.

Protéger votre site contre les attaques de falsification de requête intersite (CSRF)

Les vulnérabilités CSRF apparaissent fréquemment dans les plugins et parfois les thèmes. Lorsque les pirates les ciblent, il n'est pas difficile de se protéger. Utilisez des plugins et des thèmes de qualité auxquels vous faites confiance, supprimez ceux que vous n'utilisez pas et maintenez tous vos logiciels à jour . Vous devez également mettre en œuvre une politique de sécurité utilisateur mûrement réfléchie et envisager de ne pas utiliser de mot de passe. Si une vulnérabilité CSRF (ou toute autre) est exploitée sur votre site pour accéder aux comptes d'utilisateurs, cela ne fera pas beaucoup de bien à l'attaquant si vous utilisez des clés de passe. Personne ne peut voler ce qui n'existe pas.

En plus de gérer les mises à jour et de vous avertir des plugins et thèmes vulnérables, iThemes Security Pro facilite la configuration et la gestion des règles de sécurité basées sur les utilisateurs et les rôles. Déléguer des privilèges selon le principe du moindre privilège. Sécurisez votre login, récupération de mot de passe et formulaires de contact avec les CAPTCHA. Ne donnez pas à vos utilisateurs des capacités supérieures à celles dont ils ont besoin. Exiger que les utilisateurs disposant de privilèges plus élevés utilisent des méthodes d'authentification plus fortes. Et adoptez définitivement le moyen le plus pratique et le plus simple de vous connecter à WordPress sans mot de passe : Passkeys !