Cross Site Request Forgery par l'image!

Cross Site Request Forgery est aussi connu sous l'abbréviation CSRF. Le CSRF exploite un site web pour lequel des commandes non autorisées sont transmises par un utilisateur en qui le site web à confiance.



A la différence du XSS (Cross Site Scripting) qui exploite la confiance d'un utilisateur pour un site web particulier, le CSRF exploite la confiance qu'un site web à dans le browser de l'utilisateur.




Prenons un exemple pour nous permettre de mieux comprendre la mécanique du CSRF.

Bertrand se connecte comme tout les matins sur son site bancaire pour effectuer les opérations nécessaires à son activité professionnelle. Il commence par s'authentifier auprès de sa banque et réalise quelques transferts de fonds. Puis il va consulter ses mails personnels sur son web mail favori en oubliant de fermer la session avec son site bancaire. Il est impatient de recevoir la confirmation de la réservation d'un séjour d'une semaine en Guadeloupe. Il aimerait annoncer la bonne nouvelle à sa famille en rentrant ce soir. Bertrand trouve de nombreux mails dans sa boîte aux lettres, mais pas de confirmation de réservation. Déception!Par contre, un de ces mails non attendus lui propose d'obtenir la liste des salaires de son entreprise (un grand groupe international). Intrigué, il ne résiste pas à la tentation et clique sur l'URL proposée. Il obtient effectivement une liste de salaires mais l'information ne lui semble pas très fiable. Tant pis! Bertrand reprend consciencieusement son travail.

Ce que Bertrand ne sait pas encore c'est qu'en cliquant sur l'URL pour accèder à la liste des salaires, il a ouvert la boîte de Pandore: un script malicieux s'est exécuté pour réaliser un transfert de fonds de son compte bancaire vers un compte tiers.


Ce scénario est bien entendu une fiction et la ficelle semble bien grosse. Mais il permet, me semble t'il, de bien comprendre ce qu'est le CSRF.


La vidéo ci-dessous explique plus en détails les arcanes du CSRF à partir d'un exemple similaire.

Quelques conseils pour essayer d'éviter ce type d'attaque:

• Demander des confirmations à l'utilisateur pour les actions critiques au risque d'alourdir l'enchaînement des formulaires. La demande de confirmation peut être basée sur une ré-authentification de l'utilisateur avec la même méthode d'authentification, ou une méthode d'authentification plus forte si l'action requise est critique.
• Vérifier l'adresse URL du script appelant (referrer) au risque également d'alourdir le développement des formulaires.
• Utiliser des jetons de validité dans les formulaires pour 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.

A bientôt...