Plateforme existante

Falsification de requête inter-site (CSRF)

L'infrastructure sous-jacente protège l'application contre la falsification de requête inter-site (CSRF, Cross-Site Request Forgery), qui consiste à exploiter de manière malintentionnée un site Web auquel des commandes non autorisées sont transmises par un utilisateur jugé digne de confiance.

La CSRF (également appelée XSRF) est différente du script inter-site (CSS ou XSS), qui lui exploite la confiance d'un utilisateur vis-à-vis d'un site particulier. La CSRF revêt différents noms tels que attaque en un clic, sidejacking ou encore détournement de session.

Elle consiste à inclure un lien ou un script dans une page qui accède à un site sur lequel l'utilisateur s'est déjà ou est censé s'être déjà authentifié. Par exemple, l'utilisateur A peut naviguer sur un forum sur lequel l'utilisateur B a publié un message. Avec la CSRF, l'utilisateur B peut créer l'élément d'image HTML suivant, qui, bien loin d'être un fichier image, référence en fait un script sur le site Web de la banque de l'utilisateur A et demande un retrait de 1 000 000 de dollars :

<img src="http://bank.example/withdraw?amount=1000000&for=USER-B">

Si la banque de l'utilisateur A conserve ses informations d'authentification dans un cookie et que celui-ci n'es pas arrivé à expiration, alors la tentative de chargement de l'image enclenchée par le navigateur de l'utilisateur A envoie le formulaire de retrait à l'aide du cookie d'authentification et autorise la transaction sans le consentement de l'utilisateur A.

Dans ce scénario, le problème peut se résumer selon les trois points suivants :
  • En raison de la politique du navigateur, les cookies d'authentification sont envoyés au serveur de la banque même si la requête est effectuée depuis un autre site Web.
  • La banque de l'utilisateur A stocke les informations d'authentification dans un cookie et s'appuie sur les cookies pour le processus d'authentification.
  • La banque de l'utilisateur A ne fait pas la distinction entre les demandes GET et POST.
La protection CSRF fournie par l'infrastructure sous-jacente ne s'applique pas au premier point, puisqu'il s'agit d'une politique de navigateur. Mais elle s'applique aux deux autres points car elle utilise un cookie et un jeton supplémentaire pour l'authentification. L'utilisation d'un jeton unique dans le cadre de chaque requête transmise au serveur permet habituellement d'éviter les attaques CSRF. Dans l'infrastructure sous-jacente, ce jeton est utilisé de la façon suivante :
  1. En fin de connexion, un jeton récemment créé est défini pour la session (à des fins de validation). Il est disponible du côté client de l'application.
  2. Le jeton est utilisé comme suit :
    • Ce jeton est utilisé pour toutes les demandes AJAX et dans les utilitaires de l'infrastructure sous-jacente.
    • Lorsqu'une demande POST ou GET est transmise au serveur, l'application valide automatiquement la présence du jeton CSRF dans la demande.