La fin des CSRF dans WordPress ?

Le navigateur web Google Chrome prévoit de définir l’attribut SameSite sur tous les cookies par défaut dans la version 80 de Chrome. Google Chrome contrôle de loin la plus grande part du marché des navigateurs Web. Ses changements ont un impact significatif sur le Web. Il ne serait pas surprenant que d’autres grands navigateurs Web leur emboîtent le pas et mettent également en œuvre l’attribut de cookie SameSite par défaut. Comment ce changement va-t-il affecter le Web et la sécurité de WordPress en particulier ?

Cookies

HTTP est un protocole sans état. Les cookies ont été introduits ultérieurement pour assurer le suivi de cet état. La partie la plus importante de la sécurité lors du suivi de l'”état” est l’authentification. Les cookies aident les applications Web à déterminer si un utilisateur est authentifié ou non, pour chaque requête HTTP effectuée par votre navigateur Web.

Les cookies sont une cible très intéressante pour les pirates, car une fois que l’attaquant a votre cookie, il peut se connecter à l’application web cible en se faisant passer pour vous. Il n’a même pas besoin de votre nom d’utilisateur ou de votre mot de passe. C’est pourquoi, au fil des ans, des mesures de sécurité supplémentaires ont été ajoutées aux cookies, comme les attributs HttpOnly et Secure, ou “drapeaux”, comme on les appelle parfois.

L’attribut HttpOnly indique au navigateur Web que la valeur du cookie ne doit pas être accessible par JavaScript. Cela permet de protéger la valeur du cookie contre les attaques de type Cross-Site Scripting (XSS) et autres attaques similaires.

L’attribut Secure indique au navigateur Web de ne pas envoyer le cookie par HTTP non crypté. Il doit toujours être envoyé par HTTPS crypté. Cela permet d’éviter que le cookie ne soit intercepté par un attaquant de type Man-in-the-Middle (MitM).

Qu’est-ce que le Cross-Site Request Forgery (CSRF) ?

Pour comprendre pourquoi l’attribut SameSite est utile, nous devons d’abord comprendre ce qu’est une attaque CSRF.

Les navigateurs Web disposent d’un mécanisme de sécurité appelé “Same Origin Policy” (SOP), qui isole un site Web d’un autre, à quelques exceptions près. L’une de ces exceptions est la possibilité pour les formulaires HTML POST de transférer des données d’un domaine à un autre, y compris avec les cookies de l’utilisateur.

Pour simplifier, on parle de CSRF lorsqu’un attaquant place un formulaire HTML POST (généralement caché) sur un site Web, qui effectue une requête POST vers un autre site qui n’a pas de protections CSRF en place. La requête POST contiendra vos cookies d’authentification, de sorte que pour le site Web cible, la requête semblera provenir de votre navigateur et pourra donc y donner suite.

Une attaque assez efficace vise la page des paramètres de l’utilisateur d’une application Web qui permet à l’utilisateur de modifier son adresse électronique enregistrée, sans aucune protection CSRF (notamment en ne demandant pas le mot de passe actuel de l’utilisateur). En utilisant une attaque CSRF, un attaquant pourrait changer l’adresse électronique enregistrée pour la sienne. Il pourrait ensuite utiliser la fonctionnalité de mot de passe oublié de l’application Web pour réinitialiser le mot de passe de l’utilisateur. Et hop, il a accès au compte de l’utilisateur. Ceci n’est qu’un exemple, il existe de très nombreuses autres attaques pouvant être réalisées avec CSRF.

Qu’est-ce que l’attribut de cookie SameSite ?

L’attribut de cookie SameSite est le petit nouveau, il a été introduit pour la première fois dans Google Chrome en 2016. L’attribut SameSite a été introduit pour aider à prévenir les attaques CSRF (Cross-Site Request Forgery).

Il existe deux valeurs d’attribut SameSite, stricte et laxiste.

Strict – Votre cookie n’est jamais envoyé en cross-domain.
Laxiste – Votre cookie n’est pas envoyé en dehors du domaine pour les scénarios les plus risqués, tels que les formulaires HTML POST.
Un cookie avec un indicateur SameSite défini ressemble à ce qui suit :

Set-Cookie: session=abc123; path=/; SameSite=Lax

Effets sur la sécurité de WordPress

Comme mentionné dans les premières lignes de ce billet de blog, Google Chrome prévoit d’ajouter le cookie SameSite=Lax par défaut à tous les cookies. Cela va éradiquer la grande majorité des risques CSRF au sein des applications web à travers le web, y compris WordPress, et plus important encore, ses plugins. Un grand nombre de vulnérabilités XSS (Cross-Site Scripting) authentifiées qui affectent WordPress et ses plugins, reposent actuellement sur CSRF pour délivrer la charge utile XSS malveillante. Cela aura donc également un impact sur l’exploitation XSS. Les utilisateurs qui n’ont pas mis à jour leurs navigateurs Web vers des versions qui activent le drapeau SameSite par défaut peuvent encore être la cible d’une attaque CSRF. Mais avec le temps, nous devrions trouver de plus en plus d’utilisateurs utilisant des navigateurs web avec SameSite activé par défaut.

Alors, quand la version 80 de Google Chrome avec le drapeau SameSite par défaut sera-t-elle publiée ? Nous n’en avons aucune idée. Mais si vous le savez, faites-le nous savoir, et nous mettrons à jour ce post. La dernière version de Chrome disponible pour macOS au moment de la rédaction de cet article est la version 75, si cela aide d’une certaine manière à déterminer à quelle distance se trouve la version 80. La sortie de la version 80 stable de Chrome est prévue pour le 4 février 2020.

Pour en savoir plus sur le cookie SameSite, vous pouvez consulter les excellents articles de blog de Scott Helme :

Et pendant ce temps, vous devriez consulter notre scanner de sécurité WordPress et notre base de données des vulnérabilités des plugins WordPress. Oh, et notre propre plugin de sécurité WordPress.

Photo by Souvik Banerjee on Unsplash

Author avatar
Yvon
https://oeildelynx.net