Forgerie de requêtes intersites

Cross Site Request Forgery : les cookies comme danger

CSRF, ce sigle apparaît régulièrement dans les notes de mise à jour de WordPress Core. La méthode qui se cache derrière est devenue une vieille habitude et exploite les cookies généralement abondants d'un navigateur. Heureusement, tu peux facilement te protéger contre la Cross Site Request Forgery. Tout ce dont tu as besoin, c'est d'un peu de temps et d'attention.

Tu utilises certainement de nombreux services qui te permettent de rester connecté même après avoir quitté le site. Si tu consultes à nouveau le site, tu n'as pas besoin de saisir à nouveau tes données de connexion, tu es directement connecté. C'est bien sûr génial, car tout comme la gestion des mots de passe ou le Single Sign On, cela évite de devoir remplir des formulaires fastidieux.

Voici ce qui se passe en arrière-plan : lorsque tu te connectes pour la première fois sur le site, le site place un cookie dans ton navigateur. Il s'agit d'un petit fichier texte dans lequel certaines informations peuvent être enregistrées. Dans le cas de la connexion, il s'agit d'une chaîne de caractères générée de manière aléatoire.

Lors de ta prochaine visite sur le site, le serveur vérifie cette chaîne et, s'il peut trouver l'équivalent, te connecte automatiquement. C'est d'ailleurs la raison pour laquelle tu te déconnectes partout lorsque tu vides le cache de ton navigateur. En effet, tous les cookies sont également supprimés lors de ce processus.

Les attaques CSRF sont essentiellement des abus de confiance

Tu le sais déjà : lors d'une attaque de ce type, le service qui lit les cookies est trompé. Je t'explique exactement comment cela se passe ci-dessous à l'aide de deux exemples.

Le danger de cette manipulation réside dans le fait que quelqu'un effectue des modifications sur ton profil Facebook en ton nom, par exemple. Souvent, la Cross Site Request Forgery dépend aussi du phishing. Ici aussi, la confiance est importante - ta confiance dans les expéditeurs d'e-mails, par exemple.

Quelle est la vulnérabilité de WordPress ?

Tu n'as probablement pas entendu le terme Cross Site Request Forgery aussi souvent que tu l'as entendu. Les attaques par force brute ou Cross Site Scripting. Il y a une raison à cela : l'organisation à but non lucratif OWASP (Open Web Application Security Project) publie régulièrement une liste des dix vulnérabilités les plus critiques des applications web. Au fil des années, la CSRF est devenue un risque de sécurité de plus en plus faible et a disparu du top 10.

Cela est probablement dû au fait que les attaques CSRF sont presque aussi vieilles que l'Internet lui-même. Les développeurs professionnels sont désormais habitués à sécuriser leur code contre ces attaques. Les risques de sécurité sont donc facilement et rapidement éliminés.

WordPress est également sur le qui-vive. Par exemple, la mise à jour de sécurité 4.7.5 a été publiée sur Mai . Elle corrige six vulnérabilités qui auraient permis aux pirates de lancer une attaque via Cross Site Scripting ou Cross Site Request Forgery. Cependant, le Cross Site Scripting est souvent considéré comme beaucoup plus dangereux.

De plus, la question de la Cross Site Request Forgery a tendance à concerner davantage les plugins et les applications que les conceptions Web, les agences et les PME. Car la protection contre le CSRF est aussi une question de programmation. CSRF pourrait être pertinent par exemple pour les achats in-plugin.

Mais comment cela fonctionne-t-il maintenant ?

L'anatomie du Cross Site Request Forgery

L'idée de base derrière une attaque CSRF est relativement simple et se déroule généralement en deux étapes :

  • La victime est amenée à charger un site web manipulé ou à cliquer sur un lien, par exemple en faisant croire que le message provient d'une personne de confiance. Ou la curiosité humaine est exploitée. En d'autres termes, le phishing joue un rôle important dans ce type d'attaques.
  • En chargeant ou en cliquant sur les liens ou les sites Web manipulés, le navigateur de la victime exécute une requête HTTP sans que la victime s'en aperçoive.

Deux exemples relativement simples illustrent le fonctionnement d'une telle attaque.

Supposons que Justus veuille envoyer 100 € à Bob via le site www.bank.de et que Skinny soit à l'affût pour lancer une attaque CSRF. Skinny peut utiliser la méthode GET ou POST pour son attaque.

Au fait, les exemples suivants sont tirés des sources suivantes :

Cross Site Request Forgery avec la méthode GET

La méthode GET permet de demander une ressource à un serveur, par exemple un fichier HTML. Les paramètres nécessaires à l'appel sont simplement ajoutés à l'URL. Et comme nous le savons déjà avec les injections SQL: Une URL est relativement facile à manipuler.

Justus se connecte donc à www.bank.de et saisit toutes les données nécessaires. L'entrée suivante (totalement fictive) est transmise au serveur :

GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

Skinny construit maintenant une URL qui transfère à la place 100 000 € sur son propre compte. Elle ressemble à ceci :

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

Bien sûr, Justus doit aussi réaliser l'action qui se cache derrière le lien falsifié. C'est pourquoi Skinny envoie à Justus un mail avec un lien falsifié. Le code HTML peut ressembler à ceci, par exemple :

<a href="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>

Ou bien il lui envoie un e-mail contenant une image "invisible" (car de 0 par 0 pixels). En essayant de charger l'image, le navigateur accède à l'URL sans même que Justus s'en rende compte :

<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">

Lorsque Justus appelle le lien - consciemment ou non - les paramètres sont transmis au serveur, le virement est déclenché et voilà que 100 000 € disparaissent de son compte.

Bien sûr, Justus doit cliquer sur le lien lorsqu'il est connecté. Mais si, par malheur, un cookie de connexion de sa banque se trouve dans son navigateur, l'attaque fonctionne même s'il n'a pas ouvert le site à ce moment-là.

C'est précisément ce qui rend la Cross Site Request Forgery si sournoise : Justus n'est probablement même pas conscient de l'existence du cookie.

Cross Site Request Forgery avec la méthode POST

La méthode GET peut être utilisée dans les liens, ce qui la rend particulièrement facile à diffuser. Mais les fournisseurs peuvent faire en sorte que les demandes GET ne reçoivent en principe aucune autorisation d'écriture.

Reste la méthode POST : elle consiste à transmettre des données à un serveur pour qu'il puisse les traiter. Les données ne font pas partie de l'URL, mais sont ajoutées à l'en-tête.

Cela peut sembler un peu encombrant, mais tu connais certainement le cas d'utilisation, car les formulaires fonctionnent de cette manière.

Pour notre attaquant Skinny, cela signifie qu'il doit faire plus d'efforts, mais qu'il peut toujours arriver à ses fins.

Même scénario : Justus veut envoyer de l'argent à Bob. Il remplit donc le formulaire suivant sur www.bank.de :

<form method="POST" action="geld_ueberweisen.php">

    <input type="text" name="von">

    <input type="text" name="an">

    <input type="text" name="betrag_in_euro">

    <input type="submit">

</form>

Cela envoie la commande money_transfer.php, qui ressemble à ceci :

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}




Comme tu le vois, le code vérifie d'abord si Justus est connecté à l'aide du cookie. Ce n'est qu'alors que le virement sera effectué.

Skinny dépose maintenant un formulaire invisible sur un site manipulé, par exemple :

<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">

    <input type="text" name="von" value="Justus" style="display: hidden">

    <input type="text" name="an" value="Skinny" style="display: hidden">

    <input type="text" name="betrag_in_euro" value="100000" style="display: hidden">

    <input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">

</form>

Il envoie le lien vers ce site manipulé à Justus. Celui-ci se sent mis au défi, clique sur le bouton pour voir l'énigme - et voilà qu'il exécute sans le savoir la fonction geld_ueberweisen.php. Comme celle-ci trouve un cookie correspondant dans son navigateur, 100 000 € sont à nouveau transférés à Skinny.

Attaque par détours

D'où le nom de Cross Site Request Forgery : la commande est généralement envoyée à partir d'un autre site Web. Pour attaquer le site A, il dépose donc un code malveillant sur le site B. Ensuite, il attire la victime qui ne se doute de rien vers ce site pour que son navigateur exécute le code.

"*" indique les champs requis

Je souhaite m'abonner à la newsletter pour être informé des nouveaux articles de blog, des ebooks, des fonctionnalités et des nouvelles de WordPress. Je peux retirer mon consentement à tout moment. Merci de prendre connaissance de notre politique de confidentialité.
Ce champ sert à la validation et ne doit pas être modifié.

Voici comment te protéger contre les attaques du CSRF

La bonne nouvelle : la Cross Site Request Forgery est connue depuis des lustres. Le risque est connu et lors du développement, on travaille de manière ciblée pour l'éliminer.

La mauvaise nouvelle, c'est que tu ne peux pas vraiment te protéger du point de vue technique. Le noyau de WordPress est maintenant relativement bien protégé et, comme tu peux le voir dans les mises à jour en cours, les efforts sont constants. Comme pour les autres types d'attaques, la plupart des vulnérabilités proviennent des plugins. Tu dois donc être sûr que le développement des extensions que tu utilises est bien fait.

Cela signifie spécifiquement :

  • N'installe pas trop de plugins et seulement ceux dont tu as vraiment besoin.
  • Fais attention aux plugins qui n'ont pas été mis à jour depuis un certain temps. Ils peuvent cacher des failles de sécurité non corrigées.
  • Renseigne-toi au préalable sur les plugins que tu installes, par exemple sur leur compatibilité avec d'autres plugins ou la version de WordPress que tu utilises (pour que le plugin puisse être mis à jour).
  • Mets régulièrement à jour tes plugins et le cœur de WordPress. Car les mises à jour continues sont justement là pour combler ces failles de sécurité.
  • Sois critique vis-à-vis du phishing.
  • Si tu n'es pas sûr : regarde attentivement le plugin dans le dépôt WP. Quelles sont les évaluations, quels ont été les principaux problèmes dans le passé et est-ce que le plugin n'a peut-être pas comblé une faille de sécurité importante ?

Conclusion : la RSE est une vieille histoire

La Cross Site Request Forgery existe pratiquement depuis le début de l'ère numérique. De plus, le nombre de cas est extrêmement faible par rapport aux attaques par force brute.

C'est ce que confirme l'évaluation de l'OWASP : elle estime que l'attaque est plutôt peu répandue, facile à détecter et grave uniquement dans certains cas.

Néanmoins, il est bon de savoir comment les attaques fonctionnent. Parce que les attaques ne fonctionnent souvent que grâce à l'erreur humaine. À maintes reprises, les utilisateurs ouvrent des courriels par curiosité ou cliquent sur des liens qu'il aurait mieux valu ne pas ouvrir.

La meilleure façon de te protéger contre la Cross Site Request Forgery est donc de faire des recherches et de faire preuve d'un peu de bon sens.

As-tu aimé cet article ?

Tes évaluations nous permettent d'améliorer encore plus notre contenu.

Laisse un commentaire

Ton adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués d'un *.