Comprendre le CSRF en profondeur

Lorsque vous travaillez dans le développement web, surtout avec les cookies, nous entendons souvent des phrases comme "ce paramètre aide à prévenir le CSRF". Cependant, beaucoup de gens n'ont qu'une idée vague de ce que signifie vraiment "CSRF".

Aujourd'hui, nous allons plonger profondément dans le CSRF (falsification de requête intersite), une faille de sécurité web courante. Cela nous aidera à gérer plus efficacement les problèmes liés au CSRF.

Qu'est-ce que le CSRF ?#

Le CSRF (falsification de requête intersite) est un type d'attaque web où les attaquants trompent des utilisateurs authentifiés pour qu'ils effectuent des actions non souhaitées. En termes simples, c'est "les pirates se faisant passer pour des utilisateurs pour effectuer des actions non autorisées".

Comment fonctionne le CSRF#

Pour comprendre le CSRF, nous devons saisir quelques concepts clés :

Politique de même origine du navigateur#

La politique de même origine est une fonctionnalité de sécurité des navigateurs qui limite la manière dont un document ou un script d'une origine peut interagir avec des ressources d'une autre origine.

Une origine se compose d'un protocole (comme HTTP ou HTTPS), d'un nom de domaine, et d'un numéro de port. Par exemple, https://example.com:443 est une origine, tandis que https://demo.com:80 en est une autre.

La politique de même origine restreint l'accès aux données entre les pages de différentes origines, ce qui signifie :

• JavaScript d'une origine ne peut pas lire le DOM d'une autre origine
• JavaScript d'une origine ne peut pas lire le Cookie, IndexedDB, ou localStorage d'une autre origine
• JavaScript d'une origine ne peut pas envoyer de requêtes AJAX à une autre origine (sauf en utilisant CORS)

Cependant, pour maintenir l'ouverture et l'interopérabilité du Web (comme charger des ressources à partir de CDN ou envoyer des requêtes à des API tierces pour la journalisation), la politique de même origine ne restreint pas les requêtes réseau entre origines :

• Les pages peuvent envoyer des requêtes GET ou POST à n'importe quelle origine (comme charger des images ou soumettre des formulaires)
• Les ressources de n'importe quelle origine peuvent être incluses (comme les balises <script>, <img>, <link>, <iframe>)

Mécanisme d'envoi automatique de cookies#

Le mécanisme d'envoi automatique de cookies est une fonctionnalité importante des navigateurs. Lorsqu'un navigateur envoie une requête à un domaine, il joint automatiquement tous les cookies pour ce domaine. Ce processus est automatique et ne nécessite aucun code JavaScript ou interaction de l'utilisateur.

Ce mécanisme permet aux sites web de se souvenir facilement de l'état de connexion des utilisateurs, car chaque requête transporte automatiquement les informations d'identité de l'utilisateur. Gras Par exemple, lorsque vous vous connectez à un site web bancaire (bank.com) et obtenez un cookie d'identité, lorsque vous cliquez pour afficher votre relevé, le navigateur trouve automatiquement tous les cookies correspondant à bank.com et les attache à la requête de relevé. Le serveur de la banque peut alors vous identifier depuis l'arrière-plan et vous retourner les informations de votre relevé.

Étapes d'une attaque CSRF#

1. L'utilisateur se connecte au site web cible (comme un site bancaire) et reçoit un cookie d'authentification. Cette étape utilise le mécanisme d'envoi automatique de cookies. Après que le site bancaire a mis en place un cookie d'authentification d'identité, le navigateur attache automatiquement ce cookie à chaque requête envoyée à ce site.

2. Sans se déconnecter, l'utilisateur visite un site web malveillant. À ce point, en raison de la politique de même origine, le site malveillant ne peut pas lire directement ou modifier le cookie du site bancaire. Cela protège les informations d'identité de l'utilisateur d'être directement volées.

3. Le site malveillant inclut une requête vers le site cible (comme une opération de transfert). Bien que la politique de même origine restreigne l'accès entre origines, elle permet les requêtes réseau entre origines, telles que les requêtes initiées à travers des balises <img>, <form>. Les attaquants exploitent cette "brèche".

4. Le navigateur de l'utilisateur envoie automatiquement cette requête, ainsi que le cookie du site cible. C'est le cœur de l'attaque CSRF. Elle profite à la fois de la politique de même origine permettant des requêtes entre origines et du mécanisme d'envoi automatique de cookies (même les requêtes déclenchées par des sites malveillants transporteront des cookies correspondant au domaine).

5. Le site cible reçoit la requête, vérifie que le cookie est valide, et exécute l'opération. Le serveur ne peut pas dire si cette requête vient d'une action légitime de l'utilisateur, car le cookie attaché est valide.

Exemple d'attaque CSRF#

Illustrons comment une attaque CSRF se produit avec un exemple spécifique. Nous utiliserons un site web fictif de banque bank.com en exemple.

D'abord, l'utilisateur visite https://bank.com et se connecte à son compte.

Après une connexion réussie, le serveur définit un cookie d'authentification, par exemple :

L'utilisateur effectue une opération de transfert sur le site web de la banque, par exemple transférer $1000 à Alice. Cette opération pourrait envoyer une requête comme celle-ci :

Maintenant, supposons qu'un attaquant crée un site web malveillant https://evil.com contenant le HTML suivant :

Lorsque l'utilisateur clique sur le lien https://evil.com sans se déconnecter de son compte bancaire, comme il est déjà connecté à bank.com, le navigateur a un cookie session_id valide.

Après le chargement de la page malveillante, elle soumet automatiquement le formulaire caché, envoyant une demande de transfert à https://bank.com/transfer.

Le navigateur de l'utilisateur attache automatiquement le cookie bank.com à cette demande. Le serveur bank.com reçoit la requête, vérifie que le cookie est valide, puis exécute cette opération de transfert non autorisée.

Méthodes courantes pour prévenir les attaques CSRF#

Voici plusieurs méthodes de défense couramment utilisées contre le CSRF. Nous expliquerons en détail le principe de chaque méthode et la façon dont elle prévient efficacement les attaques CSRF :

Utiliser des jetons CSRF#

Les jetons CSRF sont l'une des méthodes les plus courantes et efficaces pour se défendre contre les attaques CSRF. Voici comment cela fonctionne :

1. Le serveur génère un jeton unique et imprévisible pour chaque session.
2. Ce jeton est intégré dans tous les formulaires pour les opérations sensibles.
3. Lorsque l'utilisateur soumet un formulaire, le serveur vérifie la validité du jeton.

Étant donné que le jeton CSRF est une valeur unique liée à la session de l'utilisateur, et que l'attaquant ne peut pas connaître ou deviner cette valeur (car elle est différente pour chaque session), même si l'attaquant trompe l'utilisateur pour envoyer une requête, la requête sera rejetée par le serveur en raison de l'absence d'un jeton CSRF valide.

Exemple de mise en œuvre :

Côté serveur (utilisation de Node.js et Express) :

Dans JavaScript côté client :

Vérification de l'en-tête Referer#

L'en-tête Referer contient l'URL de la page qui a initié la requête. En vérifiant l'en-tête Referer, le serveur peut déterminer si la requête provient d'une source légitime.

Étant donné que les attaques CSRF proviennent généralement de domaines différents, l'en-tête Referer indiquera le nom de domaine de l'attaquant. En vérifiant si le Referer est la valeur attendue, les requêtes provenant de sources inconnues peuvent être bloquées.

Cependant, il est à noter que cette méthode n'est pas totalement fiable, car certains navigateurs pourraient ne pas envoyer l'en-tête Referer, et les utilisateurs peuvent désactiver l'en-tête Referer via les paramètres du navigateur ou les plugins.

Exemple de mise en œuvre :

Utilisation de l'attribut de cookie SameSite#

SameSite est un attribut de cookie utilisé pour contrôler si les cookies sont envoyés avec des requêtes intersites. Il a trois valeurs possibles :

• Strict : Les cookies ne sont envoyés qu'avec des requêtes de même site.
• Lax : Les cookies sont envoyés avec des requêtes de même site et une navigation de premier niveau.
• None : Les cookies sont envoyés avec toutes les requêtes intersites (doit être utilisé avec l'attribut Secure).

Lorsque SameSite est défini sur Strict, il peut complètement empêcher les sites web tiers d'envoyer des cookies, prévenant ainsi efficacement les attaques CSRF. Si SameSite est défini sur Lax, il protège les opérations sensibles tout en permettant certains cas d'utilisation intersites communs (comme entrer dans un site à partir de liens externes).

Exemple de mise en œuvre :

Utiliser des en-têtes de requête personnalisés#

Pour les requêtes AJAX, des en-têtes de requête personnalisés peuvent être ajoutés. En raison des restrictions de la politique de même origine, les attaquants ne peuvent pas définir de nouveaux en-têtes dans les requêtes entre origines. Le serveur peut vérifier la présence de cet en-tête personnalisé pour vérifier la légitimité de la requête.

Exemple de mise en œuvre :

Côté client :

Côté serveur :

Vérification double des cookies#

La vérification double des cookies est une technique de défense CSRF efficace. Son principe de base est que le serveur génère un jeton aléatoire, le définit à la fois comme un cookie et l'intègre dans la page (généralement sous forme de champ de formulaire caché). Lorsque le navigateur envoie une requête, il inclut automatiquement le cookie, tandis que le JavaScript de la page envoie le jeton comme paramètre de requête. Le serveur vérifie alors si le jeton dans le cookie correspond au jeton dans les paramètres de la requête.

Bien que les attaquants puissent inclure le cookie du site cible dans les requêtes entre sites, ils ne peuvent pas lire ou modifier la valeur du cookie, ni accéder ou modifier la valeur du jeton dans la page. En exigeant que la requête inclue des jetons à la fois du cookie et des paramètres, cela garantit que la requête provient d'une source avec la permission de lire le cookie, défendant ainsi efficacement contre les attaques CSRF.

Utiliser une ré-authentification pour les opérations sensibles#

Pour les opérations particulièrement sensibles (comme changer de mot de passe ou effectuer des transferts importants), les utilisateurs peuvent être tenus de se réauthentifier. Cela fournit aux utilisateurs un point de contrôle de sécurité supplémentaire. Même si un utilisateur initie avec succès une attaque CSRF, il ne peut pas passer l'étape de ré-authentification.

Suggestions de mise en œuvre :

• Avant d'effectuer des opérations sensibles, rediriger vers une page d'authentification séparée.
• Sur cette page, exiger que l'utilisateur entre son mot de passe ou d'autres informations de vérification d'identité.
• Après vérification réussie, générer un jeton à usage unique et utiliser ce jeton dans les opérations sensibles ultérieures.

Résumé#

Grâce à cette discussion approfondie, nous espérons que vous avez maintenant une compréhension plus complète des attaques CSRF. Nous avons non seulement appris comment fonctionne le CSRF, mais aussi exploré diverses mesures de défense efficaces. Toutes ces méthodes peuvent améliorer efficacement la sécurité des applications web.

Nous espérons que ces connaissances vous aideront à mieux gérer les problèmes liés au CSRF dans votre développement quotidien et à construire des applications web plus sécurisées.