Sécurité : Attaque CSRF

L'attaque CSRF (Cross-Site Request Forgery) consiste à manipuler des utilisateurs authentifiés à une application.

Icône de calendrier
Intermédiaire
4 chapitres

L’attaque CSRF, au même titre que la faille XSS et l’injection SQL, est considérée comme l’une des failles de sécurité les plus courantes. Il est, pour cela, important de comprendre en quoi elle consiste et être en mesure de s’y prémunir.

Comprendre l’attaque CSRF

Définition

L’attaque CSRF (pour « Cross-Site Request Forgery »), en français « falsification des requêtes intersites », est une attaque qui exploite la confiance qu’un site a envers un utilisateur authentifié.

L’attaque consiste à faire en sorte qu’un utilisateur authentifié exécute des actions indésirables à son insu.

Mais comment l’attaquant peut-il bien s’y prendre ? 🤔

Pour tromper l’utilisateur, l’attaquant va généralement procéder en utilisant des techniques d’ingénierie sociale comme :

  • L’envoi de liens malveillants par email
  • La création de fausses pages web

Fonctionnement

Cette attaque ne consiste pas à usurper l’identité d’un utilisateur mais bien à le manipuler en exploitant la mécanique des sessions utilisateur.

Lorsqu’un utilisateur se connecte à un site/application, une session est créée afin de « mémoriser » son état authentifié tout au long de sa navigation.

Pour maintenir cette session active, les navigateurs stockent la plupart du temps un identifiant de session au sein d’un cookie : on parle de cookies d’authentification. Ce cookie étant automatiquement envoyé à chaque requête de l’utilisateur, le serveur saura que l’utilisateur est bien authentifié.

L’attaque CSRF consiste alors à :

  1. Faire cliquer un utilisateur authentifié sur un lien malveillant (envoyé par mail ou présent sur une page web) redirigeant vers l’URL du site cible. On dit de cette requête artificielle qu’elle est « forgée » par le pirate.
  2. Exploiter le cookie d’authentification de l’utilisateur pour que l’action associée à cette URL soit déclenchée.

En résumé, un attaquant peut créer un lien malveillant qu’une victime authentifiée à un site cible est susceptible de visiter. Lorsque la victime clique sur ce lien, une requête est envoyée au site web cible avec les informations d’authentification de la victime, déclenchant ainsi une action indésirable.

Comprendre par l’exemple

Pour bien comprendre l’attaque CSRF, prenons un exemple courant : celui de la publication de contenu non intentionnelle sur un réseau social.

Imaginons qu’un pirate, ayant constaté qu’une requête HTTP envoyée en POST sur l’URL https://target.com/post/new, permet à un utilisateur de publier un post sur son feed. Un hacker pourrait exploiter la faille CSRF en créant un script qui enverrait une requête vers cette URL, publiant ainsi un faux post.

Schéma d'une attaque CSRF
Schéma d'une attaque CSRF
1. Création d'une page malveillante

Le pirate crée une page web malveillante hébergée sur son propre domaine (par exemple, https://evil.com/csrf). Cette page contient un script qui envoie en arrière-plan une requête POST vers l’URL de publication sur le réseau social ciblé (https://target.com/post/new).

2. Incitation à visiter la page malveillante

Le pirate utilise différentes techniques d’ingénierie sociale pour inciter l’utilisateur légitime à visiter sa page malveillante. Cela pourrait être fait en envoyant un lien par e-mail.

3. L'utilisateur visite la page malveillante

L’utilisateur, étant connecté à son compte sur le réseau social dans un autre onglet ou une autre fenêtre du navigateur, visite la page malveillante sans se méfier. Et là, c’est le drame…

4. Publication non intentionnelle

Une fois sur la page malveillante, l’attaque CSRF opère en envoyant en arrière-plan une requête POST vers l’URL de publication sur le réseau social (https://target.com/post/new). Cette requête contient les données nécessaires pour créer un nouveau post sur le feed de l’utilisateur, telles que le contenu du post.

csrf.html
copié !
<!DOCTYPE html>
<html>
	<head>...</head>
	<body>
		...
		<script>
			const postData = new URLSearchParams();
			postData.append('content', 'You have been hacked 😉');

			const requestOptions = {
				method: 'POST',
				headers: {
					'Content-Type': 'application/x-www-form-urlencoded',
				},
				body: postData,
			};

			fetch('https://target.com/post/new', requestOptions)
			.then(response => {
				// Traitement de la réponse si nécessaire...
			})
			.catch(error => {
				console.error('Erreur :', error);
			});
		</script>
	</body>
</html>

Comme la requête est envoyée avec les cookies d’authentification de l’utilisateur (qui sont automatiquement inclus dans toutes les requêtes vers le domaine du réseau social), le serveur du réseau social la traite comme une demande légitime de l’utilisateur.

Le post est alors créé et publié sur le feed de l’utilisateur sans son consentement.

Risques de l’attaque CSRF

Étant donné que l’attaque CSRF consiste à manipuler un utilisateur, elle pourrait être utilisée pour déclencher n’importe quelle action que pourrait effectuer un utilisateur sur un service.

Si l’exemple précédent illustre le procédé employé par les hackers pour publier des contenus non-intentionnels, elle pourrait être utilisée dans de nombreux autres cas à l’encontre d’utilisateurs ou d’entreprises, comme :

  • Modification du profil/des paramètres de confidentialité d’un utilisateur
  • Transfert d’argent vers un compte bancaire
  • Suppression de données (articles, produits, commentaires…)
  • Ajout d’administrateur (si l’utilisateur ciblé en a les droits) conduisant à la prise de contrôle d’un site
  • Inscription à une newsletter ou à un service par abonnement
  • Abonnements à un compte de réseau social (Instagram, YouTube…)
  • Etc.

Se protéger de l’attaque CSRF

Vous l’avez compris, nul besoin d’être un génie du hacking pour mettre en place une attaque CSRF, et c’est aussi pour cela qu’il est impératif de savoir s’en prémunir.

Via la requête HTTP

Une façon de se protéger contre l’attaque CSRF est d’utiliser les données de la requête HTTP pour vérifier l’origine de la demande. Cela peut être réalisé en utilisant des mécanismes tels que l’attribut SameSite des cookies, l’en-tête Origin et l’en-tête Referer.

Ainsi, si la requête HTTP forgée part d’une boîte mail ou d’un site pirate, le serveur pourrait en être informé.

L’attribut SameSite des cookies permet de contrôler comment les cookies sont envoyés avec les requêtes cross-site.

En définissant les cookies comme SameSite=Strict, ils ne seront envoyés qu’avec les requêtes provenant du même site que celui auquel appartient le cookie, offrant ainsi une protection contre les attaques CSRF.

Header Origin

L’en-tête Origin est utilisée pour indiquer l’origine du site web qui a initié la requête.

En vérifiant l’en-tête Origin, le serveur peut s’assurer que la demande provient bien du même site que celui auquel l’utilisateur est actuellement connecté.

Referer

L’en-tête Referer indique l’URL de la ressource à partir de laquelle la requête actuelle a été initiée.

Bien que l’en-tête Referer puisse être utilisée pour vérifier l’origine de la demande, elle peut parfois poser des problèmes de confidentialité car elle expose des informations sensibles.

SameSite Cookie, Header Origin et Referer utilisent tous 3 les données de la requête HTTP pour valider l’origine de la demande et prévenir les attaques CSRF. Cependant, il convient de noter que ces méthodes peuvent être contournées dans certaines circonstances, et il est donc essentiel de les combiner avec d’autres mesures de sécurité, telles que l’utilisation de jetons CSRF, pour une protection maximale contre les attaques CSRF.

Via un jeton CSRF

Une méthode plus robuste pour se protéger contre les attaques CSRF est d’utiliser des jetons CSRF.

Les jetons CSRF sont des jetons aléatoires générés côté serveur et transmis au client au sein de la réponse HTTP.

Lorsqu’un utilisateur soumet un formulaire ou effectue une requête HTTP, le jeton CSRF associé est également envoyé avec la demande. Le serveur vérifie alors que le jeton CSRF est valide et correspond à celui attendu pour l’utilisateur actuel et la session en cours.

Ainsi, même si un attaquant parvient à déclencher une requête depuis une page malveillante, il ne pourra pas fournir le jeton CSRF correct, ce qui empêchera l’exécution de l’action non autorisée.

L’utilisation de jetons CSRF est largement considérée comme la meilleure pratique pour se protéger contre les attaques CSRF, car elle offre une protection robuste et fiable contre ce type d’attaque.

En conclusion, l’attaque CSRF représente une menace sérieuse pour la sécurité des applications web et de leurs utilisateurs. Il est essentiel de comprendre son fonctionnement et de mettre en place des mesures de protection adéquates pour minimiser les risques. L’utilisation de jetons CSRF est considérée comme la meilleure pratique pour contrer ce type d’attaque.