Les cookies, un danger : la falsification des demandes de sites

Tobias Schüring Dernière mise à jour : 21.01.2020
7 Min.
Les attaques de Cross-Site Request Forgery (CSRF) WordPress sont parmi les plus anciennes de toutes.

CSRF, cette abréviation apparaît encore et encore dans les mises à jour de sécurité et de maintenance du noyau WordPress . La méthode qui se cache derrière est désormais dépassée et exploite les nombreux cookies d'un internaute. Heureusement, vous pouvez cependant vous protéger assez facilement 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 qui vous donnent la possibilité de rester connecté même après avoir quitté le site. Si vous visitez à nouveau la page, 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 cela - tout comme une gestion de mots de passe ou un soi-disant Single Sign On - évite de remplir des formulaires ennuyeux.

Ce qui suit se passe en arrière-plan : lorsque vous vous connectez au site pour la première fois, le site web enregistre 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 également la raison pour laquelle vous êtes déconnecté partout lorsque vous videz le cache de votre navigateur. Car tous les cookies sont également supprimés au cours de ce processus.

Une attaque de la CSRF est, dans son essence même, un abus de confiance.

Comme vous pouvez le voir, dans une attaque correspondante, l'attaquant trompe le service qui lit les cookies en lui faisant croire quelque chose. Comment cela se passe exactement, je l'explique 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, modifie votre profil Facebook en votre nom, par exemple. Cependant, la falsification des demandes intersites dépend souvent aussi de l'hameçonnage. Ici aussi, la confiance devient pertinente - à savoir votre confiance dans, par exemple, les expéditeurs de courriers électroniques.

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

Quelle est la vulnérabilité de 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é au huitième rang descendue.

Cela est probablement dû en partie au fait que les attaques de la CSRF sont presque aussi anciennes que l'Internet lui-même. Les développeurs professionnels ont maintenant l'habitude de sécuriser leur code contre eux. Les risques de sécurité sont donc faciles et rapides à résoudre.

WordPress est également à l'affût. Par exemple, la mise à jour de sécurité 4.7.5 a été publiée en mai, qui a corrigé six vulnérabilités que les pirates informatiques auraient pu utiliser pour lancer une attaque via un script intersite ou une falsification de requête intersite. Souvent Le cross-site scripting est souvent considéré comme beaucoup plus dangereux.

En outre, la question de la falsification des requêtes 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. En effet, la protection contre la CSRF est aussi une question de programmation. La CSRF pourrait devenir pertinente, par exemple, dans le cas d'achats surPlugin.

Mais comment cela fonctionne-t-il maintenant ?

L'anatomie de la contrefaçon de demande de cross-site

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 piège la victime en lui faisant charger une page manipulée ou en cliquant 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. Lorsque les liens ou les pages manipulés sont chargés ou cliqués, le navigateur de la victime exécute une requête HTTP sans que la victime s'en rende compte.

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

Pour cela, supposons que Justus veuille envoyer un message à Bob via la page www.bank.de 100€, et Skinny attend pour lancer une attaque CSRF. Skinny peut maintenant utiliser, par exemple, la méthode GET ou POST pour son attaque.

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

Falsification des demandes intersites avec 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 annexés à l'URL. Et comme nous le savons déjà grâce aux 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 (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 euros sur son propre compte à la place. Il ressemble à ceci :

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

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

">qui ne peut pas résoudre ce mystère n'est pas un vrai détective !

Ou bien il lui envoie un courriel qui contient une image "invisible" (parce que 0 par 0 pixels). Lorsqu'il essaie 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 transmis au serveur, le transfert est déclenché et 100 000€ disparaissent de son compte.

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

C'est précisément ce qui rend la falsification des demandes intersites si insidieuse : la victime peut même ne pas être au courant de l'existence du cookie.

Falsification des demandes intersites avec 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 d'EEG ne reçoivent pas en principe une autorisation écrite.

La méthode POST reste la même : les données sont transférées à un serveur pour qu'il puisse les traiter. Les données ne font pas partie de l'URL, mais sont annexées à l'en-tête.

Cela peut sembler un peu encombrant, mais vous connaissez certainement le cas d'utilisation. Parce que les formulaires fonctionnent de cette façon.

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

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

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

    <input type="texte nom="de">

    <input type="texte nom="un">

    <input type="texte nom="montant_en_euro">

    <input type="soumettre>

formulaire>

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 vous pouvez le voir, le code vérifie d'abord si Justus est connecté à l'aide du cookie. Ce n'est que s'il l'est que le transfert sera exécuté.

Skinny dépose maintenant une forme invisible sur une page web manipulée, par exemple

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

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

    <input type="texte nom="un" valeur="maigre" style="display : caché">

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

    <input type="soumettre 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é. Il se sent interpellé, clique sur le bouton pour voir le puzzle, et exécute sans le savoir la fonction geld_ueberweisen.php. Lorsque celui-ci trouve un cookie correspondant dans son navigateur, 100 000 € sont à nouveau transférés à Skinny.

Attaque par détours

C'est pourquoi le nom CrossFalsification de la demande de site : le pirate envoie généralement la commande depuis un autre site. Afin d'attaquer la page A, il dépose un code malveillant sur la page B. Il attire ensuite l'utilisateur peu méfiant ici pour que son navigateur exécute le code.

Quel est le degré de dangerosité des attaques de Cross Site Request Forgery (CSRF) sur WordPress ?

Comment se prémunir contre les attaques du CSRF

La bonne nouvelle, c'est que la falsification des demandes intersites existe depuis longtemps. Les développeurs connaissent le 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 noyau de WordPress est maintenant relativement bien protégé, et comme vous pouvez le constater par les mises à jour continues, des travaux sont constamment effectués sur ce noyau. Comme pour d'autres types d'attaques, la plupart des vulnérabilités proviennent de Plugins . Vous devez donc avoir confiance dans le travail des développeurs des extensions que vous utilisez.

Cela signifie spécifiquement :

  • N'installez pas trop de Plugins et seulement le Plugins dont vous avez vraiment besoin.
  • Attention à Plugins, qui n'a pas été mis à jour par les développeurs depuis un certain temps. Des vulnérabilités de sécurité non corrigées peuvent être cachées ici.
  • Vérifiez la compatibilité du Plugins que vous installez avec les autres Plugins ou la version WordPress que vous utilisez (afin que le Plugin puisse être mis à jour).
  • Mettez régulièrement à jour votre noyau Plugins et WP. Car les mises à jour continues sont précisément là pour combler ces lacunes en matière de sécurité.
  • Vous êtes critique en matière de phishing
  • Si vous n'êtes pas sûr, regardez attentivement le site Plugin dans le dépôt WP. Quelles sont les notations, quels ont été les plus gros problèmes dans le passé et le site Plugin n'a-t-il pas comblé une faille de sécurité importante ?

Conclusion : la RSE est une vieille histoire

La falsification des requêtes intersites existe depuis le début de l'ère numérique. En outre, le nombre de cas est extrêmement faible par rapport, par exemple, aux attaques surBrute Force .

Ceci est également confirmé par l'évaluation de l'OWASP selon laquelle l'attaque est plutôt discrète, facile à détecter et grave seulement dans certains cas spécifiques. des affaires.

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.

Ainsi, que vous soyez utilisateur ou utilisateur final, la meilleure façon de vous protéger contre la falsification de demandes intersites est de faire des recherches et de faire preuve d'un peu de bon sens.

En tant qu'administrateur système, Tobias veille sur notre infrastructure et trouve chaque vis pour optimiser les performances de nos serveurs. Grâce à ses efforts inlassables, on peut souvent le trouver la nuit sur le site Slack .

Articles connexes

Commentaires sur cet article

Laisse un commentaire

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