Sécurité des applications Web - Menaces et contre-mesures

Auteur: Mohamed CHINY Durée necessaire pour le cours de Sécurité des applications Web - Menaces et contre-mesures Niveau recommandé pour le cours de Sécurité des applications Web - Menaces et contre-mesures Supports vidéo non disponibles pour ce cours Exercices de renforcement non disponibles pour ce cours Quiz non disponibles pour ce cours

Page 5: Attaque XSRF ou CSRF (Cross Site Request Forgery)

Toutes les pages

Cross Site Request Forgery - XSRF (ou CSRF)

Définition

L'attaque XSRF (ou CSRF pour Cross Site Request Forgery) est une attaque silencieuse mais redoutable. Quand elle survient, la victime ne s'en rend souvent pas compte, et ses dégâts ne se font sentir que plus tard.

Le principe de l'attaque consiste à faire exécuter une opération qui demande des privilèges spéciaux par une personne authentifiée et autorisée sans qu'elle ne s'en rende compte.

Sur le back-office d'un site web par exemple, l'administrateur et ses modérateurs ont des privilèges qui leur permettent de gérer, à leur guise, le contenu présenté en front-office. Ils peuvent alors créer, modifier, supprimer... depuis un tableau de bord facile à utiliser.

Si par exemple, l'administrateur souhaite supprimer une entrée d'une base de données, il va tout simplement cliquer sur le bouton (ou lien) approprié. Ce lien enverra les paramètres qui permettent d'identifier l'enregistrement à supprimer, et puisque l'administrateur est authentifié et dispose des privilèges nécessaires pour supprimer l'entrée, alors l'opération se passe sans encombre.

L'attaque XSRF consiste donc à forger le lien de la suppression (dans ce cas) et l'envoyer à l'administrateur, et c'est lui qui l'exécutera à son insu.

Outre la suppression, le XSRF peut causer d'autres dommages au contenu du site Web comme:
  • L'ajout ou la modification de contenu d'une manière non autorisée.
  • Exécution des commandes systèmes via l'interface Web qui peuvent avoir des conséquences désastreuses.

Exploitation

Imaginons que le lien de suppression d'un cours sur ce site est admin/cours/supp.php?num_cours=120. La page supp.php est faite de telle façon à s'exécuter uniquement si l'utilisateur est authentifié et autorisé (je vous conseille d'aller voir l'exercice sur les sessions dans le cours de PHP). Par conséquent, si l'administrateur exécute ce lien, il s'exécutera normalement et la suppression sera effectuée.

Le pirate quant-à-lui, ne dispose pas des privilèges nécessaires pour exécuter le lien, mais pour une raison quelconque, il connait le lien de la suppression ci-dessus. Tout ce qu'il a à faire, c'est d'envoyer ce lien à l'administrateur (en guise de message) en utilisant le menu contact par exemple. Mais l'astuce c'est encapsuler ce lien dans une balise image <img> comme ceci:

<img src="admin/cours/supp.php?num_cours=120" />

Si la vulnérabilité existe, il suffit que l'administrateur ouvre le message pour que le lien qui constitue la source s'exécute avec ses privilèges et la suppression sera donc faite sans faire de bruit.

Comment s'en protéger?

Au niveau du code PHP

On peut se prémunir contre les XSRF de plusieurs manières différentes:

Filtrer les entrées de l'utilisateur:

Comme pour les vulnérabilités précédentes, l'attaque XSRF se base sur l'insertion de certains caractères spéciaux dans les entrées d'un site Web (formulaire, URL...). Comme ces données là ne sont pas fiables alors il faut les filtrer en limitant leur longueur, en échappant les caractères spéciaux et en éliminant les balises à l'aide de la fonction strip_tags().

Faire confirmer toutes les actions irreversibles avant de les exécuter:

Avant de supprimer ou modifier une entrée, il convient de demander confirmation auprès de l'utilisateur, car des fois, même ce dernier peut appuyez accidentellement sur le bouton de suppression. D'autant plus, si le site était victime d'une attaque XSRF, un message de confirmation de l'action serait affiché devant l'administrateur qui se douterait alors que quelque chose d'anormale est entrain de se passer.

Vérifier la page précédente à la demande de la suppression ou modification:

En PHP il existe une variable d'environnement du nom de $HTTP_REFERER que l'on peut appeler par $_SERVER["HTTP_REFERER"] ou getenv("HTTP_REFERER"). Cette variable retourne le nom de la page qui a renvoyé le client vers la page courante. Dans le cas de la suppression par exemple, l'administrateur devrait forcément passer par la page qui contient le bouton de la suppression. Il suffit alors de vérifier si la valeur de $HTTP_REFERER correspond au nom de la page qui contient le bouton de la suppression pour s'assurer que le lien n'a pas parachuté sur le site.

Ajouter des paramètres additionnels au lien de suppression:

Il faut ajouter des paramètres supplémentaires au lien de suppression pour rendre celui-ci difficile à deviner par le pirate. Il faut aussi y inclure des paramètres dont la valeur est quasiment imprévisible comme l'empreinte de temps (Timestamp) ou un jeu de token.

Au niveau de la configuration du serveur

Comme pour les attaques précédentes, le fait d'activer l'échappement des caractères spéciaux des entrées du site sur php.ini sera un plus.