La falsification de requête intersite (CSRF)

Contexte

La falsification de requête intersite (CSRF), également connue sous le nom de XSRF, est une vulnérabilité de sécurité web qui permet à un attaquant de manipuler un utilisateur pour qu'il exécute des actions non intentionnelles au sein d'une application. Cette attaque contourne partiellement la politique de même origine, qui protège les sites web contre les interférences mutuelles.

Dans une attaque CSRF, l'attaquant force l'utilisateur à effectuer une action à son insu, telle que la modification de l'adresse e-mail ou du mot de passe de l'utilisateur, ou l'initiation d'un transfert de fonds. Selon la nature de l'attaque, l'attaquant pourrait prendre le contrôle complet du compte, des données et des fonctionnalités de l'utilisateur compromis s'il dispose d'un rôle privilégié au sein de l'application.

Trois conditions sont nécessaires pour qu'une attaque CSRF soit réussie :

Premièrement, il doit y avoir une action pertinente au sein de l'application que l'attaquant souhaite induire, comme la modification des autorisations d'un autre utilisateur ou la modification de données spécifiques à l'utilisateur.

Deuxièmement, l'exécution de l'action repose uniquement sur les cookies de session pour identifier l'utilisateur effectuant la demande, sans aucun autre mécanisme de gestion de session ou de validation de demande d'utilisateur.

Enfin, les demandes exécutant l'action ne doivent contenir aucun paramètre dont les valeurs que l'attaquant ne peut pas deviner ou déterminer.

Par exemple, si une application permet à un utilisateur de modifier l'adresse e-mail de son compte en envoyant une requête HTTP, une attaque CSRF peut manipuler l'utilisateur pour qu'il modifie son adresse e-mail en une adresse spécifiée par l'attaquant.

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5fsdfqsdlyxHfsAfE

email=wiener@user.com

Cela répond aux exigences de CSRF :

L'action de changer l'adresse e-mail d'un compte utilisateur intéresse l'attaquant. Après cette action, l'attaquant peut généralement déclencher une réinitialisation de mot de passe et prendre le contrôle complet du compte de l'utilisateur. L'application utilise un cookie de session pour identifier l'utilisateur qui a effectué la demande. Il n'y a aucun autre jeton ou mécanisme en place pour suivre les sessions des utilisateurs. L'attaquant peut facilement déterminer les valeurs des paramètres de demande nécessaires pour effectuer l'action.

Avec ces conditions en place, l'attaquant peut construire une page web contenant le code HTML suivant :

 <html>
    <body>
        <form action="https://website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@attacker-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

Si un utilisateur victime visite la page web de l'attaquant, certaines actions seront initiées. Tout d'abord, la page web de l'attaquant générera une demande HTTP vers le site web vulnérable. Si l'utilisateur est connecté au site web vulnérable, leur cookie de session sera automatiquement inclus dans la demande (dans les cas où les cookies SameSite ne sont pas utilisés). Ensuite, le site web vulnérable traitera la demande comme si elle avait été effectuée par l'utilisateur victime et effectuera les modifications nécessaires sur leur adresse e-mail.

Comment construire une attaque CSRF

Les techniques utilisées pour lancer des attaques de falsification de requête intersite (CSRF) sont comparables à celles utilisées pour les attaques de script intersite (XSS) réfléchies. L'attaquant intègre généralement du code HTML malveillant sur un site web sous leur contrôle et persuade les victimes de visiter ce site web. Cela peut être fait en envoyant à l'utilisateur un lien vers le site web par e-mail ou sur les réseaux sociaux. Alternativement, si l'attaque est placée sur un site web populaire, comme dans une section de commentaires d'utilisateur, l'attaquant peut patiemment attendre que les utilisateurs visitent le site web.

Il convient de noter que certaines attaques CSRF exploitent la méthode GET et peuvent être entièrement autonomes avec une seule URL sur le site web vulnérable. Dans de tels cas, l'attaquant n'aura peut-être pas besoin d'un site web externe et pourra fournir directement à la victime une URL malveillante sur le domaine vulnérable. Par exemple, si la demande de modification d'e-mail peut être effectuée via la méthode GET, une attaque autonome apparaîtrait comme suit :

 <img src="https://website.com/email/change?email=pwned@attacker-user.net">

Prévention des attaques CSRF

La défense la plus efficace contre les attaques de falsification de requête intersite (CSRF) consiste à incorporer un jeton CSRF dans les demandes pertinentes. Ce jeton doit avoir une entropie élevée et être imprévisible, similaire aux jetons de session. Il doit également être lié à la session de l'utilisateur et doit être rigoureusement validé avant que toute action associée ne soit exécutée.

En plus des jetons CSRF, les cookies SameSite peuvent offrir une ligne de défense supplémentaire contre les attaques CSRF, mais leur efficacité peut être partielle. Il est donc recommandé d'utiliser des cookies SameSite avec des jetons CSRF pour assurer une meilleure sécurité contre les attaques CSRF.

Vulnérabilités CSRF courantes

Les vulnérabilités les plus remarquables associées à la falsification de requête intersite (CSRF) résultent d'erreurs commises lors de la validation des jetons CSRF.

Prenons l'exemple précédent et supposons maintenant que l'application a ajouté un jeton CSRF dans la demande pour modifier l'adresse e-mail de l'utilisateur :

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLn

csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@user.com

L'ajout d'un jeton CSRF à la demande devrait fournir une protection contre les attaques CSRF car il élimine les conditions nécessaires à une vulnérabilité CSRF. Cela implique que l'application ne dépend plus uniquement des cookies pour la gestion de session et que la demande porte un paramètre dont la valeur échappe au contrôle d'un attaquant. Néanmoins, la défense CSRF peut être compromise de plusieurs manières, laissant l'application vulnérable aux attaques CSRF.

Par exemple, certaines applications peuvent valider correctement le jeton uniquement lorsque la demande utilise la méthode POST mais ignorer la validation lorsque la méthode GET est utilisée. Dans un tel scénario, un attaquant pourrait passer à la méthode GET pour éviter la validation et exécuter une attaque CSRF :

 GET /email/change?email=pwned@attacker-user.net HTTP/1.1
Host: website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLn

Certaines applications valident le jeton avec précision lorsqu'il est inclus dans la demande, mais négligent de le valider si le jeton est absent. Cela offre une ouverture aux attaquants pour supprimer l'ensemble du paramètre qui contient le jeton (et non seulement sa valeur), contournant ainsi la validation et effectuant une attaque CSRF :

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLn

email=pwned@attacker-user.net

Certaines applications ne vérifient pas que le jeton correspond à la même session que l'utilisateur soumettant la demande. Au lieu de cela, l'application maintient une collection globale de jetons qu'elle a émis et accepte tout jeton qui apparaît dans cette collection. Dans un tel scénario, un attaquant pourrait se connecter à l'application en utilisant son compte, récupérer un jeton valide, puis transmettre ce jeton à l'utilisateur victime lors de l'attaque CSRF.

Dans une variante de la vulnérabilité mentionnée ci-dessus, certaines applications lient le jeton CSRF à un cookie qui diffère de celui utilisé pour suivre les sessions. Cela se produit souvent lorsqu'une application utilise deux frameworks distincts, l'un pour la protection CSRF et l'autre pour la gestion de session, qui ne sont pas intégrés entre eux :

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXNP; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv

csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tW&email=wiener@user.com

Cette situation est plus complexe à exploiter, mais présente toujours une vulnérabilité. Si le site Web comporte un élément permettant à un attaquant de placer un cookie dans le navigateur d'une victime, une attaque peut être lancée. L'attaquant peut se connecter à l'application en utilisant son propre compte, acquérir un jeton valide et son cookie associé, exploiter le comportement de configuration des cookies pour placer son cookie dans le navigateur de la victime et fournir son jeton à la victime lors de l'attaque CSRF.

Dans une autre variante de la vulnérabilité mentionnée ci-dessus, certaines applications ne conservent aucun enregistrement côté serveur des jetons émis. Au lieu de cela, elles répliquent chaque jeton à la fois dans un cookie et dans un paramètre de requête. Lors de la validation ultérieure d'une demande, l'application ne vérifie que si le jeton soumis dans le paramètre de requête correspond à la valeur fournie dans le cookie. Cette défense contre les attaques CSRF est parfois appelée "double soumission" et est promue car elle est simple à implémenter et élimine le besoin d'état côté serveur :

 POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjySz; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpb

csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpb&email=wiener@user.com

Dans ce cas, un attaquant peut une fois de plus effectuer une attaque CSRF, à condition que le site Web dispose d'un élément de configuration de cookie. Ici, l'attaquant n'a pas besoin d'obtenir lui-même un jeton valide. Au lieu de cela, il peut fabriquer un jeton (éventuellement dans le format requis, s'il est vérifié), utiliser le comportement de configuration de cookie pour insérer son cookie dans le navigateur de la victime, et fournir son jeton à la victime pendant l'attaque CSRF.

Défenses basées sur le Referer contre les attaques CSRF

En plus des défenses basées sur le jeton CSRF, certaines applications utilisent l'en-tête HTTP Referer pour tenter de se protéger contre les attaques CSRF, souvent en confirmant que la demande provient de leur propre domaine. Cette approche est généralement moins efficace et fréquemment vulnérable à l'évasion.

L'efficacité de la validation de Referer dépend de l'existence de l'en-tête. Dans une telle situation, un attaquant peut concevoir son exploit CSRF de manière à ce que le navigateur de la victime élimine l'en-tête Referer de la demande résultante. Plusieurs méthodes peuvent accomplir cela, mais la plus simple est d'utiliser une balise META dans la page HTML hébergeant l'attaque CSRF :

 <meta name="referrer" content="never">

Si une application valide que le domaine initiant le Referer correspond à la valeur attendue, la validation du Referer peut être contournée. Dans un tel scénario, l'attaquant peut le configurer comme un sous-domaine de son propre domaine :

 http://website.com.attacker-website.com/csrf-attack