Les principales failles de sécurité des applications web actuelles, telles que recensées par l'OWASP: principes, parades et bonnes pratiques de développement

4.5 Falsification de requête inter-sites (CSRF)

4.5.1 Principe

D. Gollmann [14] 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é.

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.

Figure 19 - Principe d'une attaque CSRF stockée

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

4.5.2 Exemples d'attaque

L'exemple suivant reprend la table « messages » et le script PHP pour l'insertion de données (voir ' paragraphe 3.2.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>

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

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.