Pentest Web – Faille CSRF

Les attaques Web cherchant à utiliser une faille CSRF sont plutôt courantes, bien qu’elles puissent assez facilement être contrées. L’existence d’une vulnérabilité de type CSRF provient souvent d’une mauvaise compréhension de son principe par les développeurs. Comme les conséquences d’une attaque CSRF peuvent être catastrophiques, voyons comment elle fonctionne et surtout, quelle sécurité informatique mettre en place pour l’éviter.

Découvrez les différents types de test d’intrusion web.

Qu’est-ce qu’une faille CSRF ?

CSRF est l’acronyme de « Cross Site Request Forgery ». Autrement dit en français, il s’agit d’une falsification de requête inter-site. Derrière ce nom un peu barbare se cache une technique assez simple. Le principe consiste à faire exécuter une action sur un serveur, via une requête http, par un utilisateur authentifié, sans qu’il en ait conscience.

Le hacker a pu repérer les requêtes utilisées par le site cible et les reproduire. Le simple chargement d’une page web dans son navigateur permet d’enclencher la requête cachée vers un autre site. Si l’utilisateur est authentifié sur le site ciblé, alors la requête a des chances d’être exécutée et le hacker d’obtenir les résultats escomptés.

Comment est exploitée une faille CSRF ?

L’exploitation d’une faille CSRF se fait en plusieurs temps.

Dans un premier temps, l’utilisateur ciblé par l’attaque informatique navigue sur un site conçu par le hacker. Cela peut par exemple être la copie d’un site connu. L’utilisateur peut y avoir été amené par un lien dans un email, une newsletter.

Dans un deuxième temps, lorsque l’utilisateur charge la page du site, il déclenchera sans s’en rendre compte une requête http. Cette requête peut être contenue dans une simple balise html, une image par exemple. Mais au lieu de charger une image, le navigateur exécutera la requête prévue.

Enfin, la requête http est envoyée vers le site cible. Si au même moment l’utilisateur est déjà authentifié sur le site, alors la requête va être acceptée par le serveur et exécutée. N’importe quelle action non protégée contre les attaques CSRF peut être envisagée. Imaginons que l’url permettant de modifier le mot de passe d’un utilisateur du site soit la suivante : « http://monsitecible.com/password/edit/123/monnouveaumdp ». La requête va demander au site de modifier le mot de passe de l’utilisateur n°123 et de le remplacer par « monnouveaumdp ». Si l’utilisateur, authentifié sur le site, charge une page contenant cette requête http, le mot de passe de l’utilisateur n°123 sera effectivement modifié. Il ne reste plus alors qu’au hacker à s’identifier avec cet utilisateur et son nouveau mot de passe.

Protéger son site contre les failles CSRF

Bien entendu, un test d’intrusion permettra de révéler les failles CSRF d’un site ou d’une application. Malheureusement, si le pentest détecte la vulnérabilité et que le site est en ligne depuis un certain temps, rien ne dit qu’elle n’a pas déjà été exploitée.

Les actions les plus efficaces ont donc lieu en amont, lors de la conception et du développement du site. Les développeurs doivent équiper le site de deux fonctionnalités très simples.

L’authentification à l’aide d’un jeton

Un jeton est une chaîne de caractères générée aléatoirement. Chaque échange entre le serveur et le navigateur va être contrôlé. Si l’utilisateur est authentifié, le serveur envoie un jeton au navigateur. Lorsque le navigateur envoie une nouvelle demande au serveur, comme pour modifier un mot de passe par exemple, il fournira également le jeton d’authentification. De cette façon, le serveur aura l’assurance de l’identité de l’utilisateur. Une requête provenant d’un site malveillant ne disposera pas du jeton et sera donc automatiquement rejetée.

Une demande de confirmation systématique

Ajouter systématiquement une demande de confirmation par l’utilisateur lorsque des actions affectant les données sont demandées permet d’empêcher une attaque CSRF. La requête malveillante peut par exemple demander le changement du mot de passe, mais elle sera bloquée par la demande de confirmation que seul un utilisateur pourrait donner. Le principe est le même si pour le changement du mot de passe, le site demande de fournir l’ancien.

Vérifier le HTTP_REFERER, une fausse bonne idée ?

Le serveur web enregistre généralement la provenance de la requête de l’utilisateur dans une variable nommée HTTP_REFERER. Il est alors facile de vérifier si la requête provient du même ou bien d’un site tiers. Cela permet de filtrer les requêtes.

Si l’idée paraît intéressante, c’est une fausse bonne idée en termes de cybersécurité. En effet, cette variable est définie par le navigateur et peut par conséquent être aisément falsifiée. Vous n’avez donc aucune garantie que la requête http proviennne bien du site autorisé.

Se prémunir des attaques CSRF en tant qu’utilisateur

L’utilisateur lui-même peut se prémunir des attaques CSRF en appliquant systématiquement certaines règles :

• Se déconnecter d’un site après avoir terminé.
• Ne pas se servir de la fonctionnalité du navigateur permettant d’enregistrer ses identifiants et mots de passe.
• Ne pas autoriser les sites à se souvenir de lui.
• Utiliser un autre ordinateur, un autre navigateur et une fenêtre de navigation privée pour accéder aux sites sensibles.