Falsification de requête intersites (CSRF)

1. Principe

D. Gollmann montre qu'une attaque par falsification de requête intersites (Cross-Site Request Forgery ou session riding ou CSRF ou XSRF) a un fonctionnement assez proche d'une attaque XSS. La principale différence est que l'utilisateur au travers de son navigateur ne sera pas la victime mais sera celui qui va effectuer une action malveillante sur l'application cible. Une attaque CSRF va exécuter du code malveillant dans une application Web au travers de la session d'un utilisateur connecté.

Comme pour XSS, il existe deux modes opératoires.

Dans une attaque CSRF par réflexion (reflected CSRF), l'attaquant crée une page Web qui comporte un formulaire invisible par exemple. Ce dernier contient un script caché qui lance des actions de l'application. L'attaquant piège l'utilisateur en mettant un lien vers cette page dans un courrier électronique ou sur des réseaux sociaux. Quand l'utilisateur affiche cette page, le navigateur va interpréter le code malicieux et va tenter d'exécuter une fonctionnalité de l'application cible. Si l'utilisateur s'y est récemment connecté, l'application va exécuter la commande sans le consentement de l'utilisateur. Cette attaque fonctionne car les informations d'authentification qui ont préalablement été saisies par l'utilisateur sont envoyées automatiquement par le navigateur au serveur. L'attaquant n'a donc pas besoin de se connecter à l'application pour exécuter des commandes frauduleuses. Cependant l'attaque ne fonctionne pas si l'utilisateur ne s'est pas connecté.

Dans une attaque CSRF stockée (stored CSRF), c'est l'application elle-même qui présente le code malicieux à l'utilisateur. Pour ce faire l'attaquant a réussi a inséré du code malicieux dans les données de l'application Web. Chaque fois qu'un utilisateur parcourra la page qui va présenter ce code, le navigateur va l'interpréter et par conséquent va exécuter une commande de l'application. L'application va alors accepter d'exécuter cet ordre comme si la demande provenait de l'utilisateur. Cette attaque a plus de chances de réussir car l'utilisateur s'est déjà connecté et utilise l'application. L'attaquant n'a pas de besoin de piéger un utilisateur.

Une attaque par CSRF rend les défenses contre les attaques XSS inopérantes.

2. Exemples d'attaque

L'exemple suivant reprend la table « messages » et le script PHP pour l'insertion de données (voir paragraphe 3.3.2). Si ce script se nomme « add_message.php », le site de l'attaquant pourra utiliser le code suivant pour le faire exécuter par l'utilisateur :

Figure 24 - Code HTML pour réaliser une attaque CSRF

Sélectionnez

<form method="GET" id="reflected_CSRF" name="reflected_CSRF" action="add_message.php"> 
    <input type=hidden name="numsujet" value="6"> 
    <input type=hidden name="nom" value="CSRF"> 
    <input type=hidden name="message" value="action frauduleuse"> 
</form> 
<script>document.reflected_CSRF.submit()</script>

L'utilisateur en parcourant la page de l'attaquant est alors automatiquement redirigé vers la page « add_message.php » avec les paramètres numsujet=6, nom=CSRF et message=action frauduleuse.3. Parade et bonnes pratiques

Bien que XSS et CSRF soient proches dans le principe, se protéger des attaques XSS ne permet pas de se protéger des attaques CSRF.

Pour se protéger, il faut utiliser uniquement des requêtes POST. Les méthodes GET doivent être bannies. Attention toutefois, dans les servlet Java la méthode « doGet() » fait appel à la méthode « doPost() » en redirigeant l'ensemble des paramètres. Dans ce cas l'utilisation de requêtes GET fonctionne. C'est pourquoi l'utilisation de POST n'est pas une protection suffisante.

Pour les pages qui manipulent des données sensibles, il faut demander à l'utilisateur de s'authentifier à nouveau. Cela permet de s'assurer que l'utilisateur est conscient de l'action et l'approuve.

L'utilisateur doit toujours vérifier que le lien sur lequel il clique est bien celui de l'application qu'il veut utiliser.