Protection CSRF avec en-tête CORS Origin et jeton CSRF

103

Cette question concerne uniquement la protection contre les attaques de falsification de requêtes intersites.

Il s'agit spécifiquement de: La protection via l'en-tête d'origine (CORS) est-elle aussi bonne que la protection via un jeton CSRF?

Exemple:

Alice est connectée (à l'aide d'un cookie) avec son navigateur à " https://example.com ". Je suppose qu'elle utilise un navigateur moderne.
Alice visite " https://evil.com ", et le code côté client de evil.com effectue une sorte de requête à " https://example.com " (scénario CSRF classique).

Alors:

Si nous ne vérifions pas l'en-tête Origin (côté serveur) et aucun jeton CSRF, nous avons une faille de sécurité CSRF.
Si nous vérifions un jeton CSRF, nous sommes en sécurité (mais c'est un peu fastidieux).
Si nous vérifions l'en-tête Origin, la demande du code côté client de evil.com devrait être bloquée aussi bien que lors de l'utilisation d'un jeton CSRF - sauf s'il est possible que le code de evil.com définisse l'en-tête Origin.

Je sais que cela ne devrait pas être possible avec XHR (voir par exemple Sécurité pour le partage de ressources cross-origin ), du moins pas, si nous faisons confiance aux spécifications du W3C pour être correctement implémentées dans tous les navigateurs modernes (pouvons-nous?)

Mais qu'en est-il des autres types de demandes - par exemple, la soumission d'un formulaire? Chargement d'une balise script / img / ...? Ou de toute autre manière qu'une page peut utiliser pour créer (légalement) une demande? Ou peut-être un piratage JS connu?

Remarque: je ne parle pas de

applications natives,
navigateurs manipulés,
bogues de script intersite dans la page example.com,
...

— Chris Lercher
source

Je crois que de nombreux mandataires suppriment l'en-tête d'origine.

— thefourtheye

Et pour les balises d'envoi de formulaire et img / script, nous devrions nous fier aux CSP, pas sûrs des anciens navigateurs.

— thefourtheye

@thefourtheye: Étant donné que la connexion est initiée via TLS, l'utilisateur a un problème beaucoup plus urgent que CSRF si un proxy peut lui / elle passer au milieu.

— Perseids

@thefourtheye, pourquoi se déshabilleraient-ils Origin? Cela annulerait la protection CORS.

— Paul Draper

J'aime cette question et ses réponses car elles portent sur quelque chose de spécifique, mais elles me rappellent aussi la différence entre CSRF et CORS. (J'admets que ce ne sont pas des concepts facilement confusables ... Mais j'arrive toujours à les confondre.)

— The Red Pea

Réponses:

sachez que cela ne devrait pas être possible avec XHR (voir par exemple Sécurité pour le partage de ressources cross-origin), du moins pas, si nous faisons confiance à la spécification W3C pour être correctement implémentée dans tous les navigateurs modernes (pouvons-nous?)

À la fin de la journée, vous devez «faire confiance» au navigateur client pour stocker en toute sécurité les données de l'utilisateur et protéger le côté client de la session. Si vous ne faites pas confiance au navigateur client, vous devez arrêter d'utiliser le Web pour autre chose que du contenu statique. Même avec l'utilisation de jetons CSRF, vous faites confiance au navigateur client pour qu'il obéisse correctement à la même politique d'origine .

Bien qu'il y ait eu des vulnérabilités de navigateur antérieures telles que celles dans IE 5.5 / 6.0 où il était possible pour les attaquants de contourner la politique de même origine et d'exécuter des attaques, vous pouvez généralement vous attendre à ce qu'elles soient corrigées dès qu'elles sont découvertes et avec la plupart des navigateurs se mettant à jour automatiquement. , ce risque sera en grande partie atténué.

Mais qu'en est-il des autres types de demandes - par exemple, la soumission d'un formulaire? Chargement d'une balise script / img / ...? Ou de toute autre manière qu'une page peut utiliser pour créer (légalement) une demande? Ou peut-être un piratage JS connu?

L'en- Origintête n'est normalement envoyé que pour les demandes interdomaines XHR. Les demandes d'image ne contiennent pas d'en-tête.

Remarque: je ne parle pas de

applications natives,

navigateurs manipulés,

bogues de script intersite dans la page example.com,

Je ne sais pas si cela relève ou non des navigateurs manipulés, mais les anciennes versions de Flash permettaient de définir des en-têtes arbitraires qui permettraient à un attaquant d'envoyer une requête avec un en- referertête usurpé depuis la machine de la victime afin d'exécuter une attaque.

— SilverlightFox
source

L'exemple de Flash est un bon exemple - et peut-être que d'autres plugins peuvent avoir une vulnérabilité similaire. Je ne peux (malheureusement) protéger Alice de CSRF que si elle utilise un navigateur moderne, etc., c'est clair. Mais il n'est pas déraisonnable que, même en tant qu'utilisateur soucieux de la sécurité, elle ait peut-être installé des plugins tiers - en particulier lorsqu'ils proviennent de grandes entreprises (dignes de confiance). Même s'ils peuvent écrire des plugins sûrs, je ne suis pas convaincu à 100%, s'ils pensent aussi à CSRF! Donc, à moins que les sandbox du navigateur n'empêchent les plugins de violer le SOP (est-ce que c'est peut-être le cas?), Je recommande plutôt de s'en tenir au jeton CSRF.

— Chris Lercher du

@ChrisLercher: Oui, les plugins modernes semblent un peu plus robustes. Cependant, à tout moment, une nouvelle version pourrait être publiée pour permettre à un attaquant de l'exploiter de manière à contourner les protections du navigateur. La meilleure façon de le gérer (par exemple, jeton / en-tête) dépendra de la sensibilité de vos données et de l'acceptabilité d'un tel risque. Flash obéit à une SOP, mais l'origine d'un plugin Flash est le site à partir duquel il a été chargé (plutôt que le site appelant comme JavaScript). Il y a un crossdomain.xmlqui peut permettre la communication entre domaines.

— SilverlightFox

Le contenu Web ne peut pas altérer l'en-tête Origin. De plus, dans le cadre de la même politique d'origine, une origine ne peut même pas envoyer d'en-têtes personnalisés à d'autres origines. [1]

Ainsi, la vérification de l'en-tête Origin est tout aussi efficace pour bloquer les attaques que l'utilisation d'un jeton CSRF.

La principale préoccupation en s'appuyant sur cela est de savoir si cela permet à toutes les demandes légitimes de fonctionner. Le demandeur connaît ce problème et a mis en place la question pour écarter les cas majeurs (pas d'anciens navigateurs, HTTPS uniquement).

Les fournisseurs de navigateurs suivent ces règles, mais qu'en est-il des plugins? Ce n'est peut-être pas le cas, mais la question ne tient pas compte des «navigateurs manipulés». Qu'en est-il des bogues dans le navigateur qui permettent à un attaquant de forger l'en-tête Origin? Il peut y avoir des bogues qui permettent au jeton CSRF de fuir également entre les origines, il faudrait donc plus de travail pour affirmer que l'un est meilleur que l'autre.

— client
source

Je viens de tester Firefox 47 et il n'envoie pas d'en-tête d'origine pour un message de formulaire d'origine croisée (une manière courante d'attaquer les services REST qui n'activent pas CORS pour XHR), donc je ne pense pas qu'une vérification d'en-tête d'origine serait efficace si l'utilisateur utilise Firefox.

— Andy

Pour référence, le problème de Firefox qui n'envoie pas d'en-tête "Origin" est suivi sur Bugzilla: bugzilla.mozilla.org/show_bug.cgi?id=446344 Vous pourriez revenir à la vérification de l'en-tête "Referer" dans ce cas, mais d'après mon expérience, certains Les utilisateurs de Firefox bloquent l'en-tête "Referer" pour des raisons de confidentialité (bien qu'à mon humble avis, il suffirait de supprimer le chemin et la requête).

— Steffen