Si vous implémentez une protection particulière contre les attaques de connexion CSRF (Cross-Site Request Forgery, contrefaçon de requêtes trans-sites), vous rencontrerez des problèmes quand un utilisateur a plusieurs pages ouvertes sur votre site, et essaie ensuite de se connecter avec l'une d'elles. Ce document explique ce problème, et comment le résoudre.
CSRF et les attaques de connexion CSRF
Dans le cas normal d'une attaque CSRF, l'utilisateur est déjà connecté au site ciblé (par exemple, leur banque). L'utilisateur charge alors une page sur un autre site, construite de manière malveillante. Cette page envoie une requête HTTP vers le site web ciblé : la requête présente un intérêt particulier (par exemple, le transfert d'argent vers l'attaqueur). Le site ciblé permet la requête car il pense que puisque l'utilisateur est connecté au site, elle est faite par l'utilisateur.
Dans le cas d'une attaque de connexion CSRF, l'utilisateur charge une page construite de manière malveillante qui connecte l'utilisateur sur le site ciblé, mais en tant que l'attaquant : le site ciblé dépose alors un cookie de session dans le navigateur de l'utilisateur. L'attaquant peut accéder au compte plus tard, et récupérer les informations que le site a collectées sur l'utilisateur.
Protection contre CSRF : jetons CSRF déclinés à partir de l'identifiant de session
Une protection courante contre les attaques normales CSRF consiste pour les sites web de générer un jeton à partir de l'identifiant de session de l'utilisateur, et l'inclure dans les pages qu'ils servent : ensuite les requêtes POST doivent inclure ce jeton, qui est vérifié par le serveur. Ceci veut dire que les requêtes POST ne peuvent pas être faites depuis d'autres domaines, car ils ne peuvent pas accéder au jeton utilisé pour la vérification.
Avec les attaques de connexion CSRF, bien sûr, l'utilisateur n'est pas encore connecté au site web. Donc le site prépare une première session dès que l'utilisateur visite une page. Elle est utilisée pour générer le jeton CSRF jusqu'à ce que l'utilisateur se connecte. Une fois l'utilisateur connecté, un nouvel identifiant de session est généré, et un jeton CSRF est regénéré.
Le problème avec Persona
Le problème avec Persona survient quand l'utilisateur n'est pas encore identifié, et a des pages de votre site web dans deux différents onglets, A et B. Les pages contiennent le même jeton CSRF, généré à partir de l'identifiant de la première session. Ensuite l'utilisateur se connecte dans l'onglet A, et le site genère un nouvel identifiant de session, et de par le fait, un nouveau jeton CSRF. Mais l'onglet B a toujours l'ancienne page de chargée, contenant l'ancien jeton, maintenant invalide.
Dans des circonstances ordinaires cela n'aurait pas d'importance : dès que l'onglet B recharge la page, ou que l'utilisateur navigue sur une nouvelle page, le jeton CSRF inclus est mis à jour. Mais lorsque Persona a généré une assertion en réponse à un appel à navigator.id.request(), Persona appelle onlogin pour chaque onglet qui a chargé le site Web, et pas seulement pour celui qui a réclamé l'assertion. Dès l'appel du gestionnaire onlogin sur l'onglet B, il essaie d'envoyer en POST l'assertion vers le serveur qui utilise l'ancien jeton CSRF — et le serveur lance alors une erreur CSRF.
La solution
La solution consiste pour le gestionnaire de onlogin à envoyer une requête GET qui réclame un nouveau jeton CSRF et vérifie que l'utilisateur est déjà identifié. Si l'utilisateur est bien identifié, le gestionnaire n'a plus qu'à recharger la page. Sinon il utilise le nouveau jeton CSRF pour envoyer l'assertion en POST au serveur.