Les cookies, un danger : la falsification des demandes inter-sites

7 Min.
Les attaques de Cross-Site Request Forgery (CSRF) WordPress sont parmi les plus anciennes de toutes.

CSRF, cette abréviation apparaît à plusieurs reprises dans les mises à jour de sécurité et de maintenance du WordPress -Core. La méthode qui se cache derrière est désormais dépassée et tire parti des nombreux cookies d'un internaute. Heureusement, il est assez facile de se protéger contre la falsification des demandes intersites. Tout ce dont vous avez besoin, c'est d'un peu de temps et d'attention.

Vous utilisez probablement aussi un certain nombre de services où il est possible de rester connecté même après avoir quitté le site. Si vous visitez à nouveau le site, vous n'avez pas besoin de saisir à nouveau vos données de connexion, mais vous êtes directement connecté. Pour l'utilisateur, c'est bien sûr formidable, car - tout comme une gestion des mots de passe ou un soi-disant authentification unique - formulaire fastidieux à remplir.

Ce qui suit se passe en arrière-plan : lorsque vous vous connectez au site pour la première fois, le site web stocke un cookie dans votre navigateur. Il s'agit d'un petit fichier texte dans lequel certaines informations peuvent être stockées. Dans le cas où vous restez connecté, il s'agit d'une chaîne de caractères générée de manière aléatoire.

Lors de votre prochaine visite sur le site, le serveur vérifie cette chaîne de caractères et, s'il peut trouver la contrepartie correspondante, il vous connecte automatiquement. C'est d'ailleurs la raison pour laquelle vous êtes déconnecté partout lorsque vous Cache du navigateur vide. En effet, tous les cookies sont également supprimés au cours de ce processus.

Une attaque du CSRF est essentiellement un abus de confiance

Vous le remarquez déjà : avec une attaque correspondante, l'attaquant feint quelque chose au service qui lit les cookies. La manière dont cela se passe exactement est expliquée ci-dessous à l'aide de deux exemples.

Le danger de cette manipulation réside dans le fait qu'un tiers, c'est-à-dire l'agresseur, par exemple, modifie votre profil Facebook en votre nom. Toutefois, la contrefaçon de demandes intersites dépend aussi fréquemment du phishing. C'est pourquoi la confiance devient également pertinente dans ce domaine, à savoir votre confiance dans l'expéditeur du courrier, par exemple.

Les attaques de Cross Site Request Forgery (CSRF) WordPress peuvent être évitées par le bon sens.

A quel point la situation est-elle en danger WordPress ?

Vous n'avez probablement pas entendu le terme "Cross-Site Request Forgery" aussi souvent que Brute Force Attaques ou scripting intersites. 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 dans les applications web. Sur la liste préliminaire pour 2017 La CSRF occupe la 8e place sur 10. En 2007 et 2010, l'attaque a encore atterri à la 5e place, En 2013, il est passé à la 8e place off.

L'une des raisons de cette situation est probablement que les attaques du CSRF sont presque aussi vieilles que l'Internet lui-même. Les développeurs professionnels sont désormais capables de sécuriser leur code contre ce risque. Les risques de sécurité sont donc assez faciles et rapidement résolus.

Avec l'WordPress un d'entre eux est également sur ses gardes. Par exemple, la mise à jour de sécurité 4.7.5, publiée en mai, a corrigé six vulnérabilités qui auraient pu être utilisées par des pirates pour lancer une attaque par le biais de scripts intersites ou de requêtes intersites falsifiées. Fréquemment mais pourtant scripting intersites est considéré comme beaucoup plus dangereux.

En outre, la question de la falsification des demandes intersites tend à être plus pertinente pour Plugin- et les développeurs d'applications que pour les concepteurs de sites web, les agences et les PME. Car la protection contre la CSRF est aussi une question de programmation. Le CSRF pourrait être pertinent, par exemple, pour les in-Plugin-sera acheté.

Mais comment cela fonctionne-t-il maintenant ?

L'anatomie de la contrefaçon de demande intersite

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

  1. Le hacker fait en sorte que la victime charge une page manipulée ou clique sur un lien, par exemple en se faisant passer pour une personne de confiance ou en exploitant la curiosité humaine. En d'autres termes, le phishing joue un rôle important dans ce type d'attaque.
  2. Lors du chargement ou du clic sur les liens ou les pages manipulés, le navigateur de la victime exécute une requête HTTP sans que la victime ne s'en aperçoive.

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

Supposons que Justus veuille faire venir Bob sur le site www.bank.com Transférez 100€, et Skinny sera à l'affût d'une attaque du CSRF. Skinny peut maintenant utiliser la méthode GET ou POST pour son attaque.

Au fait, les exemples suivants proviennent des sources suivantes :

Faux de demande intersite pour la méthode GET

La méthode GET est utilisée pour demander une ressource à un serveur, par exemple un fichier HTML. Les paramètres requis pour l'appel sont simplement ajoutés à l'URL. Et comme nous l'avons déjà entendu de la part de Injections SQL savoir : Une URL est relativement facile à manipuler.

Justus se connecte donc à www.bank.com et saisit toutes les données requises. L'entrée suivante (complètement fictive) serait transmise au serveur :

GET http://bank.com/transfer.do?acct=BOBetrag=100 HTTP/1.1

Skinny construit maintenant une URL qui transfère 100.000€ sur son propre compte à la place. Voici à quoi cela ressemble :

http://bank.com/transfer.do?acct=SKINNYetrag=100000

Bien sûr, Justus doit exécuter l'action cachée derrière le faux lien. C'est pourquoi Skinny Justus envoie un mail avec un faux lien. Le code HTML peut ressembler à ceci, par exemple :

">Si vous ne pouvez pas résoudre ce mystère, vous n'êtes pas un vrai détective !

Ou bien il lui envoie un courriel contenant une image "invisible" (parce que 0 par 0 pixels). En essayant de charger l'image, le navigateur accède à l'URL sans que Justus ne s'en aperçoive :

Lorsque Justus appelle le lien - consciemment ou inconsciemment - les paramètres sont transférés au serveur, le transfert est initié et 100.000€ disparaissent de son compte.

Bien entendu, Justus doit cliquer sur le lien lorsqu'il est connecté. Cependant, si malheureusement il y a un cookie de connexion de sa banque dans son navigateur l'attaque fonctionne même s'il n'a pas ouvert la page à ce moment-là.

C'est exactement ce qui rend la contrefaçon de demandes intersites si sournoise : la partie lésée peut même ne pas savoir que le cookie existe.

Falsification de demandes intersites par la méthode POST

La méthode GET peut être utilisée dans les liens et est donc particulièrement facile à diffuser. Cela joue naturellement en faveur de l'attaquant en termes de distribution. Toutefois, les fournisseurs peuvent désormais s'assurer que les demandes de GET ne reçoivent pas d'autorisation écrite par principe.

La méthode POST reste la même : les données sont ici transférées à un serveur afin de pouvoir être traitées ultérieurement. Toutefois, les données ne font pas partie de l'URL, mais sont jointes à l'en-tête.

Cela peut sembler un peu volumineux, mais je suis sûr que vous connaissez la demande. Parce que les formulaires fonctionnent de cette façon.

Pour notre agresseur, Skinny, cela signifie que même s'il doit faire plus d'efforts, il peut encore atteindre son but.

Même scénario : Justus veut transférer de l'argent à Bob. Alors il se remplit wwww.bank.com le formulaire suivant :

<formulaire méthode="POSTE action="wire_transfer.php">

    <entrée type="texte nom="de">

    <entrée type="texte nom="sur">

    <entrée type="texte nom="montant_en_euro">

    <entrée type="envoyer">

formulaire>

Cela envoie la commande geld_ueberweisung.php qui ressemble à ceci

si(isset($_FORM["de"]) && isset($_FORM["sur"]) &&isset($_FORM["crowd_in_euro"]) && isset($_CMOKIE["user_logged in"]))

{

    transMoney("de", "sur", " montant ".) ;

    echo "Transfert réussi !";

}

Comme vous pouvez le voir, le code vérifie d'abord si Justus est connecté en utilisant le cookie. Le transfert ne sera exécuté que si c'est le cas.

Skinny dépose désormais une forme invisible sur un site web manipulé, par exemple

<formulaire méthode="POSTE action="http://www.bank.com/money_transfer.php">

    <entrée type="texte nom="de" valeur="Justus" style="display : caché">

    <entrée type="texte nom="sur" valeur="Maigre" style="display : caché">

    <entrée type="texte nom="montant_en_euro" valeur="100000" style="display : caché">

    <entrée type="envoyer" valeur="Celui qui ne peut pas résoudre ce mystère n'est pas un vrai détective !">

formulaire>

Il envoie à Justus le lien vers ce site web manipulé. Se sentant mis au défi, il clique sur le bouton pour voir le puzzle ; et il exécute sans le savoir la fonction geld_ueberweisung.php. Comme celui-ci trouve un cookie correspondant dans son navigateur, 100.000€ sont à nouveau transférés à Skinny.

attaque par des moyens détournés

D'où le nom Cross-Faux de demande de site : le pirate envoie généralement la commande depuis un autre site. Donc pour attaquer le côté A, il dépose un code malveillant sur le côté B. Il attire ensuite l'utilisateur peu méfiant ici pour que son navigateur exécute le code.

Quel est le danger des attaques par Cross Site Request Forgery (CSRF) WordPress ?

Comment se protéger contre les attaques du CSRF

La bonne nouvelle : le Cross-Site Request Forgery existe depuis longtemps. Les développeurs sont conscients du risque et travaillent spécifiquement pour l'éliminer.

La mauvaise nouvelle, c'est que vous ne pouvez pas vraiment vous en protéger sur le plan technique. Le WordPress noyau est maintenant relativement bien protégé, et comme vous pouvez le constater par les mises à jour continues, il est constamment travaillé. Comme pour d'autres types d'attaques, la plupart des vulnérabilités sont liées Pluginsà ces attaques. Vous devez donc avoir confiance dans le travail des développeurs des extensions que vous utilisez.

Cela signifie concrètement :

  • Ne pas en installer trop Plugins et seul le Pluginsdont vous avez vraiment besoin
  • Attention à Pluginsceux qui n'ont pas été mis à jour par les développeurs depuis longtemps. Les failles de sécurité non résolues peuvent être cachées ici.
  • Pour en savoir plus sur le Pluginsque vous installez, par exemple, sur leur compatibilité avec d'autres Plugins ou la WordPress version que vous utilisez (afin qu'elle Pluginpuisse être mise à jour).
  • Mettez régulièrement à jour votre Pluginset le WP-Core. Car les mises à jour continues sont précisément là pour combler ces failles de sécurité.
  • Vous critiquez le phishing
  • Si vous n'êtes pas sûr, jetez un coup d'œil Plugin dans le dépôt WP. Quelles sont les notations, quels ont été les plus gros problèmes dans le passé, et est-ce que le Plugin une faille de sécurité très médiatisée n'a peut-être pas été comblée ?

Conclusion : la CSRF, c'est du passé

Le Cross-Site Request Forgery existe pratiquement depuis le début de l'ère numérique. En outre, le nombre de cas est plus élevé que dans, par exemple Brute Force Attaques extrêmement petit.

Cela confirme également l'évaluation de l'OWASPIci, on suppose que l'attaque est plutôt petite, facile à détecter et seulement dans certains cas spécifiques, grave est.

Mais il est bon de savoir comment les attaques fonctionnent. Souvent, les attaques ne fonctionnent que grâce à l'erreur humaine. À maintes reprises, les utilisateurs ouvrent des mails par curiosité ou cliquent sur des liens qu'ils n'auraient pas dû ouvrir.

Ainsi, que vous soyez utilisateur ou opérateur, la meilleure façon de vous protéger contre la contrefaçon des requêtes intersites est de faire appel à la recherche et à un peu de bon sens.

Articles connexes

Commentaires sur cet article

Ecrire un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués par * .