Cross-site request forgery

Les attaques de type Cross-Site Request Forgery (abrégées CSRF prononcées sea-surfing ou parfois XSRF) utilisent l'utilisateur comme déclencheur, celui-ci devient complice sans en être conscient. L'attaque étant actionnée par l'utilisateur, un grand nombre de systèmes d'authentification sont contournés.

Illustration

Supposons que Bob soit l'administrateur d'un forum et qu'il soit connecté à celui-ci par un système de sessions. Alice est un membre de ce même forum, elle veut supprimer un des messages du forum. Comme elle n'a pas les droits nécessaires avec son compte, elle utilise celui de Bob grâce à une attaque de type CSRF.

• Alice arrive à connaître le lien qui permet de supprimer le message en question.
• Alice envoie un message à Bob contenant une pseudo-image à afficher (qui est en fait un script). L'URL de l'image est le lien vers le script permettant de supprimer le message désiré.
• Bob lit le message d'Alice, son navigateur tente de récupérer le contenu de l'image. En faisant cela, le navigateur actionne le lien et supprime le message, il récupère une page web comme contenu pour l'image. Ne reconnaissant pas le type d'image associé, il n'affiche pas d'image et Bob ne sait pas qu'Alice vient de lui faire supprimer un message contre son gré.

Caractéristiques

Les caractéristiques du CSRF sont un type d'attaque qui :

• Implique un site qui repose sur l'authentification globale d'un utilisateur
• Exploite cette confiance dans l'authentification pour autoriser des actions implicitement
• Envoie des requêtes HTTP à l'insu de l'utilisateur qui est dupé pour déclencher ces actions

Pour résumer, les sites sensibles au CSRF sont ceux qui acceptent les actions sur le simple fait de l'authentification à un instant donné de l'utilisateur et non sur une autorisation explicite de l'utilisateur pour une action donnée.

Prévention

Demander des confirmations à l'utilisateur pour les actions critiques 

Au risque d'alourdir l'enchaînement des formulaires.

Demander une confirmation de l'ancien mot de passe à l'utilisateur pour changer celui-ci ou changer l'adresse mail du compte.

Utiliser des jetons de validité dans les formulaires 

Faire en sorte qu'un formulaire posté ne soit accepté que s'il a été produit quelques minutes auparavant : le jeton de validité en sera la preuve. Le jeton de validité doit être transmis en paramètre et vérifié côté serveur.

Éviter d'utiliser des requêtes HTTP GET pour effectuer des actions 

Cette technique va naturellement éliminer des attaques simples basées sur les images, mais laissera passer les attaques fondées sur JavaScript, lesquelles sont capables très simplement de lancer des requêtes HTTP POST.

Effectuer une vérification du « referer » dans les pages sensibles 

Connaître la provenance du client permet de sécuriser ce genre d'attaques. Ceci consiste à bloquer la requête du client si la valeur de son « referer » est différente de la page d'où il doit théoriquement provenir.

Voir aussi

Articles connexes

• Vulnérabilité (informatique)
• XSS
• Cross-site cooking

Liens externes

• (fr) Introduction aux Cross-Site request forgeries
• (fr) JDN Développeurs
• (en) The cross-site request forgery FAQ
• (fr) CSRForm - Outil d'aide à l'exploitation de failles de type CSRF
• (fr) PHP: $_SERVER - Manual. Voir le paragraphe concernant l'élément « HTTP_REFERER ».
• (fr) Se protéger des attaques CSRF

• Portail de la sécurité informatique