Une application web présente une vulnérabilité : si un utilisateur connecté ouvre une page piège préparée par un attaquant, son navigateur envoie au site légitime des requêtes qu'il n'a pas voulues, comme un virement ou une modification de paramètres. Quelle contre-mesure est appropriée ?

Réponse : A. Incorporer dans les formulaires des opérations importantes une valeur aléatoire imprévisible propre à la session (jeton), et vérifier que cette valeur est correcte à la réception de chaque requête

Cette vulnérabilité s'appelle la falsification de requête intersite (CSRF, cross-site request forgery). Lorsqu'il envoie une requête au site légitime, le navigateur y joint automatiquement les cookies de ce site (les informations de la session connectée), quelle que soit la page d'où part la requête. Si le serveur considère une requête comme une opération authentique de l'utilisateur connecté sur la seule base des cookies, il accepte donc aussi les requêtes qu'une page piège a fait envoyer par le navigateur. La contre-mesure de base consiste à incorporer une valeur aléatoire imprévisible propre à la session (jeton CSRF) uniquement dans les formulaires légitimes et à la vérifier sur le serveur. La page piège ne peut pas connaître cette valeur et ne peut donc pas construire une requête valide. D'autres mesures consistent à utiliser l'attribut SameSite pour que les cookies ne soient pas joints aux requêtes provenant d'autres sites, et à exiger une nouvelle saisie du mot de passe avant les opérations importantes comme un virement. La différence avec le XSS est que le XSS incorpore un script malveillant dans le site, alors que la CSRF fait envoyer par le navigateur de l'utilisateur des requêtes d'apparence légitime.