accueilLogicielsDéveloppement et Qualité LogicielsFailles de sécurité des applications Web
 

Falsification de requête inter-sites (CSRF)


1. Principe
2. Exemples d’attaque
3. Parade et bonnes pratiques

Principe

 D. Gollmann [1] montre qu’une attaque par falsification de requête inter-sites (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é.

PNG - 110 ko
Principe d’une attaque CSRF par réflexion

 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 chance 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.

PNG - 109.4 ko
Principe d’une attaque CSRF stockée

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 :

<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.

Parade et bonnes pratiques

 Bien que XSS et CSRF soit 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.

 

Retour vers le haut de la page   PDF
Article précédent Page d'accueil Article suivant
< Référence directe non sécurisée à un objet Sommaire | Mauvaise configuration de sécurité >

 

Guillaume HARRY
Envoyer un courriel

 

Contenu sous licence Creative Commons CC-BY-NC-ND


[1] D. Gollmann. Securing Web applications. Dans Information Security Technical Report, chapitre 1-9, Elsevier, 2008


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits