Les vulnérabilités du web sont omniprésentes et ne cessent d’augmenter. Il est plus important que jamais de préserver la sécurité et la vie privée de vos utilisateurs. Ne pas s’attaquer aux vulnérabilités du web peut conduire à une réputation ruinée et à de lourdes amendes de la part des autorités de régulation, et vous perdrez également la confiance de vos utilisateurs.
Les sites web et les applications web sont vulnérables aux logiciels malveillants, au spam et à d’autres attaques – cet article se concentre sur l’un de ces vecteurs d’attaque : les attaques CSRF (Cross-Site Request Forgery). Les attaques CSRF sont particulièrement inquiétantes car elles peuvent se produire à l’insu de l’utilisateur. Elles sont également difficiles à détecter pour un développeur ou un propriétaire de site web, car les requêtes malveillantes ressemblent beaucoup à des requêtes authentiques.
Cet article examine les attaques CSRF, leur fonctionnement et les mesures que vous pouvez prendre pour vous y préparer.
Consultez notre guide vidéo pour tout savoir sur les attaques CSRF
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 requêtes malveillantes sans qu’il s’en rende compte.
Généralement, une attaque CSRF implique des requêtes de changement d’état car l’attaquant ne reçoit pas de réponse. Parmi les exemples de ces requêtes, on peut citer la suppression d’un enregistrement, la modification d’un mot de passe, l’achat d’un produit ou l’envoi d’un message. Toutes ces actions peuvent se produire à l’insu de l’utilisateur.
L’attaquant malveillant utilise généralement l’ingénierie sociale pour envoyer à un utilisateur peu méfiant un lien par l’intermédiaire d’un tchat ou d’un e-mail.
Lorsque l’utilisateur clique sur le lien, il exécute les commandes définies par l’attaquant.
Par exemple, en cliquant sur un lien, l’utilisateur peut transférer des fonds de son compte. Il peut également modifier l’adresse e-mail d’un utilisateur, l’empêchant ainsi d’accéder à nouveau à son compte.
Comment fonctionne une attaque CSRF ?
Amener l’utilisateur à initier une requête de changement d’état alors qu’il est connecté est la première étape, et la plus cruciale, d’une attaque CSRF. Avec les attaques CSRF, l’attaquant cherche à amener un utilisateur authentifié à soumettre à son insu une requête web malveillante à un site web ou à une application web. Ces requêtes peuvent consister en des cookies, des paramètres d’URL et d’autres types de données qui semblent normales à l’utilisateur.
Pour qu’une attaque CSRF réussisse, les conditions suivantes doivent être réunies :
- Un utilisateur authentifié doit être connecté à une application web qui utilise des cookies pour la gestion de session.
- Un attaquant doit créer une requête falsifiée avec changement d’état.
- Les requêtes authentiques traitées par le serveur cible ne doivent pas contenir de paramètres imprévisibles. Par exemple, la requête ne doit pas attendre un mot de passe comme paramètre à des fins de vérification avant d’initier la requête de changement d’état.
La méthode la plus courante pour mener à bien des attaques CSRF consiste à utiliser des cookies dans des applications dont la politique en matière de cookies SameSite est faible. Les navigateurs web incluent les 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 relative aux cookies SameSite définit la manière dont le navigateur traite les cookies dans les contextes de navigation intersites. S’il est défini sur strict, le cookie n’est pas partagé dans les contextes de navigation intersites, ce qui permet d’éviter les attaques CSRF. Le navigateur attache le cookie dans tous les contextes intersites s’il est défini sur none. L’application est alors vulnérable aux attaques CSRF.
Lorsqu’un utilisateur soumet à son insu une requête malveillante par l’intermédiaire d’un navigateur web, les cookies enregistrés font apparaître la requête comme légitime aux yeux du serveur. Le serveur répond alors à la demande en modifiant le compte de l’utilisateur, en changeant l’état de la session ou en renvoyant les données demandées.
Examinons de plus près deux exemples d’attaques 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 G ET utilisée par une application web de banque financière, où l’attaque exploite une requête GET et la livraison d’un hyperlien.
Supposons que la requête GET pour transférer de l’argent ressemble à ceci :
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1Dans la requête authentique ci-dessus, l’utilisateur demande à transférer 1000 dollars sur un compte à l’adresse 547895 en guise de paiement pour 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 requiert pas de détails qu’un attaquant pourrait ne pas connaître. Ainsi, pour lancer une attaque, un pirate n’aurait qu’à modifier les paramètres de cette requête (le montant et le numéro de compte) pour créer une fausse requête exécutable.
La demande malveillante serait efficace pour tous les utilisateurs de la banque tant qu’ils ont des sessions en cours gérées par des cookies.
Voici à quoi ressemblerait la fausse demande de transfert de 500 dollars vers 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 d’une attaque CSRF.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Une fois cette étape franchie, le pirate doit trouver un moyen de tromper l’utilisateur pour qu’il envoie cette requête alors qu’il est connecté à son application de banque en ligne. L’un des moyens d’y parvenir consiste à 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 le pirate a trouvé les adresses électroniques correctes de ses cibles, il peut envoyer ce lien par courrier électronique à de nombreux clients de la banque. Ceux qui cliqueront sur le lien alors qu’ils sont connectés déclencheront la requête d’envoyer au pirate 500 dollars à partir du compte connecté.
CSRF pour une requête POST
Voyons comment la même institution financière pourrait subir un CSRF si elle n’acceptait que des requêtes POST. Dans ce cas, la livraison de l’hyperlien utilisée dans l’exemple de la requête GET ne fonctionnerait pas. Par conséquent, pour qu’une attaque CSRF réussisse, il faudrait que l’attaquant crée un formulaire HTML. La demande authentique d’envoi de 1000 dollars 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=547895Cette 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 requête pour effectuer une attaque CSRF.
L’attaquant n’a qu’à ajouter un cookie authentique à une requête falsifiée pour que le serveur traite le transfert. Pour cela, il peut créer un lien hypertexte d’apparence inoffensive qui conduit l’utilisateur à une page web de déclenchement ressemblant à celle-ci :
<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. Lorsqu’un utilisateur authentifié visite la page, le navigateur ajoute le cookie de session avant de transmettre la demande au serveur. Le serveur transfère alors 500 dollars sur le compte du pirate.
3 façons d’atténuer 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 :
- Utiliser des jetons CSRF
- L’utilisation de l’en-tête referrer
- 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é contre les attaques CSRF attribue à chaque session un jeton unique qu’il partage avec le serveur et le navigateur du client. Lorsqu’un navigateur envoie une requête sensible, le serveur s’attend à ce qu’elle contienne le jeton CSRF attribué. S’il s’agit d’un jeton erroné, le serveur l’abandonne. Pour des raisons de sécurité, le jeton CSRF n’est pas stocké dans les cookies de session du navigateur du client.
Vulnérabilités potentielles des jetons CSRF
Bien que les jetons CSRF constituent une excellente mesure de sécurité, cette méthode n’est pas à l’abri des attaques. Voici quelques-unes des vulnérabilités qui accompagnent les jetons CSRF :
- Contournement de la validation – Certaines applications sautent l’étape de vérification si elles ne trouvent pas de jeton. Si un pirate accède au code qui contient 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=93j9d8eckke20d433Un 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 groupe de jetons pour valider les sessions des utilisateurs au lieu de désigner un jeton spécifique pour une session. Un pirate n’a qu’à obtenir l’un des jetons déjà présents dans le pool pour se faire passer pour n’importe quel utilisateur du site.
Un attaquant peut se connecter à une application en utilisant son compte pour obtenir un jeton, tel que :
[application_url].com?csrf_token=93j9d8eckke20d433Et comme les jetons sont mis en commun, l’attaquant peut copier et utiliser ce même jeton pour se connecter à un autre compte utilisateur, car vous l’utiliserez à nouveau :
- Les CSRF peuvent être des jetons copiés dans le cookie – Certaines applications copient les paramètres liés à un jeton dans le cookie de l’utilisateur. Si un pirate accède à ce cookie, il peut facilement créer un autre cookie, le placer dans un navigateur et exécuter une attaque CSRF.
Ainsi, un pirate peut se connecter à une application en utilisant son compte et ouvrir le fichier cookie pour voir ce qui suit :
Csrf_token:93j9d8eckke20d433Il peut ensuite utiliser ces informations pour créer un autre cookie afin de mener à bien l’attaque
- Jetons non valides – Certaines applications ne font pas correspondre les jetons CSRF à la session d’un utilisateur. Dans ce cas, un attaquant peut se connecter à une session, obtenir un jeton CSRF similaire à ceux mentionnés ci-dessus et l’utiliser pour orchestrer une attaque CSRF sur la session d’une victime.
Comment prévenir les attaques CSRF à l’aide de l’en-tête Referrer ?
Une autre stratégie de prévention des attaques CSRF consiste à utiliser l’en-tête referrer. Dans le protocole HTTP, les en-têtes de référence indiquent l’origine des requêtes. Ils sont généralement utilisés à des fins d’analyse, d’optimisation et de journalisation.
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 serveur vérifie l’origine de la source de la demande et détermine l’origine de la cible de la requête. S’ils correspondent, la requête est autorisée. En cas de non-concordance, le serveur rejette la requête.
L’utilisation d’en-têtes de référence est beaucoup plus facile que l’utilisation de jetons parce qu’elle ne nécessite pas l’identification individuelle de l’utilisateur.
Vulnérabilités potentielles de l’en-tête Referrer
Tout comme les jetons CSRF, les en-têtes référents présentent des vulnérabilités importantes.
Tout d’abord, les en-têtes de référence ne sont pas obligatoires et certains sites envoient des requêtes sans en avoir. Si le CSRF n’a pas de politique pour traiter les requêtes sans en-tête, les attaquants peuvent utiliser les requêtes sans en-tête pour exécuter des attaques par changement d’état.
En outre, cette méthode est devenue moins efficace avec l’introduction récente de la politique de référence (referrer policy). Cette spécification empêche les fuites d’URL vers d’autres domaines, en donnant aux utilisateurs plus de contrôle sur les informations contenues dans l’en-tête referrer. Ils peuvent choisir d’exposer une partie des informations de l’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 referrer pour toutes les requêtes provenant de cette page. Ce faisant, il est difficile pour les applications qui s’appuient sur les en-têtes de référence de prévenir les attaques CSRF à partir d’une telle page.
Comment Kinsta se protège contre les attaques CSRF
Outre l’utilisation de l’en-tête referrer et des jetons CSRF, il existe une troisième option, bien plus simple : choisir un service d’hébergement sécurisé comme Kinsta pour vos sites et applications web constitue une barrière bien plus solide et sûre entre les attaquants et vos utilisateurs.
En plus des fonctions de sécurité essentielles telles que les sauvegardes automatiques, l’authentification à deux facteurs et les protocoles SFTP et SSH, l’intégration de Cloudflare de Kinsta offre une protection au niveau de l’entreprise avec une protection basée sur l’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 à traiter les graves vulnérabilités non authentifiées dans les extensions et les thèmes, y compris des règles spécifiques qui recherchent les vulnérabilités CSRF.
Résumé
La falsification des requêtes intersites (CSRF) est une attaque qui incite les utilisateurs authentifiés à initier des requêtes de changement d’état de manière non intentionnelle. Ces attaques ciblent les applications qui ne peuvent pas faire la différence entre les requêtes de changement d’état valides et les requêtes falsifiées.
L’attaque CSRF ne peut réussir que sur des applications qui s’appuient sur des cookies de session pour identifier les utilisateurs connectés et dont la politique en matière de cookies SameSite est faible. Elles 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 la vérification de l’en-tête referrer puissent empêcher certaines attaques CSRF, ces deux mesures présentent des vulnérabilités potentielles qui peuvent rendre vos mesures préventives inutiles si vous n’êtes pas prudent.
En migrant vers une plateforme d’hébergement sécurisée comme Kinsta, vous sécurisez vos sites web ou vos applications web contre les attaques CSRF. De plus, l’intégration de Kinsta avec Cloudflare permet d’éviter certaines attaques CSRF.
Laisser un commentaire