Articles

XSS vs CSRF

Dans cette section, nous allons expliquer les différences entre XSS et CSRF, et discuter si les jetons CSRF peuvent aider à prévenir les attaques XSS.

Quelle est la différence entre XSS et CSRF?

Le cross-site scripting (ou XSS) permet à un attaquant d’exécuter un JavaScript arbitraire au sein du navigateur d’un utilisateur victime.

La falsification de requête intersite (ou CSRF) permet à un attaquant d’inciter un utilisateur victime à effectuer des actions qu’il n’a pas l’intention de faire.

Les conséquences des vulnérabilités XSS sont généralement plus graves que celles des vulnérabilités CSRF :

  • CSRF ne s’applique souvent qu’à un sous-ensemble d’actions qu’un utilisateur est capable d’effectuer. De nombreuses applications mettent en œuvre des défenses CSRF en général mais négligent une ou deux actions qui sont laissées exposées. À l’inverse, un exploit XSS réussi peut normalement inciter un utilisateur à effectuer n’importe quelle action qu’il est capable d’exécuter, indépendamment de la fonctionnalité dans laquelle la vulnérabilité apparaît.
  • CSRF peut être décrit comme une vulnérabilité « à sens unique », en ce sens que si un attaquant peut inciter la victime à émettre une requête HTTP, il ne peut pas récupérer la réponse de cette requête. À l’inverse, XSS est  » bidirectionnelle « , en ce sens que le script injecté par l’attaquant peut émettre des requêtes arbitraires, lire les réponses et exfiltrer des données vers un domaine externe choisi par l’attaquant.

Les jetons CSRF peuvent-ils empêcher les attaques XSS ?

Certaines attaques XSS peuvent effectivement être empêchées par une utilisation efficace des jetons CSRF. Considérons une simple vulnérabilité XSS réfléchie qui peut être trivialement exploitée comme ceci :

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

Maintenant, supposons que la fonction vulnérable inclut un jeton CSRF :

https://insecure-website.com/status?csrf-token=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz&message=<script>/*+Bad+stuff+here...+*/</script>

En supposant que le serveur valide correctement le jeton CSRF, et rejette les requêtes sans jeton valide, alors le jeton empêche effectivement l’exploitation de la vulnérabilité XSS. L’indice ici est dans le nom : « cross-site scripting », au moins dans sa forme réfléchie, implique une requête intersite. En empêchant un attaquant de forger une requête cross-site, l’application empêche l’exploitation triviale de la vulnérabilité XSS.

Des mises en garde importantes apparaissent ici :

  • Si une vulnérabilité XSS réfléchie existe ailleurs sur le site au sein d’une fonction qui n’est pas protégée par un jeton CSRF, alors cette XSS peut être exploitée de la manière normale.
  • Si une vulnérabilité XSS exploitable existe n’importe où sur un site, alors cette vulnérabilité peut être exploitée pour faire exécuter des actions à un utilisateur victime, même si ces actions sont elles-mêmes protégées par des jetons CSRF. Dans cette situation, le script de l’attaquant peut demander à la page concernée d’obtenir un jeton CSRF valide, puis utiliser le jeton pour effectuer l’action protégée.
  • Les jetons CSRF ne protègent pas contre les vulnérabilités XSS stockées. Si une page qui est protégée par un jeton CSRF est également le point de sortie d’une vulnérabilité XSS stockée, alors cette vulnérabilité XSS peut être exploitée de la manière habituelle, et la charge utile XSS s’exécutera lorsqu’un utilisateur visitera la page.