web-dev-qa-db-fra.com

Pourquoi l'en-tête Access-Control-Allow-Origin est-il nécessaire?

Je comprends le but du Access-Control-Allow-Credentials header , mais ne voit pas quel problème le Access-Control-Allow-Origin l'en-tête résout.

Plus précisément, il est facile de voir comment, si le cross-domaine AJAX requêtes avec des informations d'identification étaient autorisées par défaut, ou si un serveur crache Access-Control-Allow-Credentials en-têtes à chaque demande, les attaques CSRF seraient rendues possibles et ne pourraient pas être exécutées autrement. La méthode d'attaque dans ce scénario serait simple:

  1. Attirez un utilisateur sans méfiance sur ma page malveillante.
  2. JavaScript sur ma page malveillante envoie une AJAX - avec cookies - vers une page d'un site cible.
  3. JavaScript sur ma page malveillante analyse la réponse à la demande AJAX, et en extrait le jeton CSRF.
  4. JavaScript sur ma page malveillante utilise tous les moyens - soit AJAX ou un navire traditionnel pour une demande CSRF, comme un formulaire POST - pour effectuer des actions en utilisant la combinaison de les cookies de l'utilisateur et leur token CSRF volé.

Cependant, ce que je ne peux pas voir, c'est à quoi sert l'objectif de ne pas autoriser non accrédité cross-domain AJAX requêtes sans Access-Control-Allow-Origin entête. Supposons que je crée un navigateur qui se comporte comme si chaque réponse HTTP qu'il recevait contenait

Access-Control-Allow-Origin: *

mais nécessitait toujours un Access-Control-Allow-Credentials en-tête avant d'envoyer des cookies avec plusieurs domaines AJAX requêtes.

Étant donné que les jetons CSRF doivent être liés à des utilisateurs individuels (c'est-à-dire à des cookies de session individuels), la réponse à un non crédité AJAX = la demande n'exposerait aucun jeton CSRF. Quelle méthode d'attaque - le cas échéant - le navigateur hypothétique décrit ci-dessus exposerait-il à ses utilisateurs?

httpcsrfsame-origin-policycors
50
Mark Amery

Si je vous comprends bien, vous dites pourquoi le navigateur bloque-t-il l'accès à une ressource qui peut être obtenue gratuitement sur Internet si les cookies ne sont pas impliqués? Considérez bien ce scénario:

www.evil.com - contient du code de script malveillant cherchant à exploiter les vulnérabilités CSRF.

www.privatesite.com - il s'agit de votre site externe, mais au lieu de le verrouiller à l'aide d'informations d'identification, vous l'avez configuré pour être sans cookies et pour n'autoriser l'accès qu'à partir de l'IP statique de votre routeur domestique.

mynas (192.168.1.1) - il s'agit de votre serveur domestique, uniquement accessible sur votre réseau wifi domestique. Étant donné que vous êtes le seul que vous autorisez à vous connecter à votre réseau wifi domestique, ce serveur n'est pas protégé par des informations d'identification et permet un accès anonyme et sans cookies.

www.privatesite.com Et mynas génèrent des jetons dans des champs de formulaire masqués pour la protection contre CSRF - mais comme vous avez désactivé l'authentification, ces jetons ne sont liés à aucune session utilisateur.

Maintenant, si vous visitez accidentellement www.evil.com, Ce domaine pourrait faire des demandes à www.privatesite.com/turn_off_ip_lockdown En passant le jeton obtenu par la demande interdomaine, ou même à mynas/format_drive En utilisant la même méthode.

Peu probable, je sais, mais je suppose que la norme est écrite pour être aussi robuste que possible et cela n'a pas de sens de supprimer Access-Control-Allow-Origin Car cela ajoute des avantages dans des scénarios comme celui-ci.

25
SilverlightFox

Ce qui m'a dérangé au départ avec les politiques CORS, c'était leur application aveugle quelle que soit la ressource/le type, je pense que le sentiment résonne assez bien avec votre question. Spécification W3 conseille que:

Une ressource qui est accessible au public, sans vérification de contrôle d'accès, peut toujours retourner en toute sécurité un en-tête Access-Control-Allow-Origin dont la valeur est "*"

Ainsi, alors que le scénario dans @ réponse de SilverlightFox est possible, à mon humble avis, il était peu probable qu'il soit pris en compte lors de l'écriture de la spécification. Au lieu de cela, W3 semble être entraîné par une mentalité "tout ce qui n'est pas explicitement autorisé devrait être restreint" dans ce cas, qui se retourne contre lorsque les en-têtes corrects ne sont pas 't set ou le support manque par les navigateurs individuels:

  • Applications côté client riches utilisant des API RESTful tierces où l'authentification, le cas échéant, est envoyée avec chaque demande afin qu'il n'y ait pas de "session" à Hijack (c'est sans état pour vous!). Néanmoins, les réponses .json sont soumises à CORS, vous devez donc maintenant convaincre le tiers d'implémenter jsonp ou un Access-Control-Allow-Origin header, ou abandonnez et configurez un tunnel vers leur point de terminaison (devinez lequel j'utiliserai).

  • Webfonts sont soumis à CORS , bien que afaik seul Firefox ait implémenté ce projet de spécification. Cela signifie que si vous utilisez un CDN pour les polices (ou un sous-domaine pour tout le contenu statique), il vaut mieux *-activée!

  • Points bonus herp derp pour les CDN qui ne répondent pas avec un * en-tête mais en écho à la demande Origin valeur d'en-tête à la place: si elle est mise en cache sur un proxy avec un ...-Allow-Origin: domainA, vos utilisateurs d'autres domaines ne pourront pas y accéder sans cachebusting (ce qui est une sorte de revers en termes d'avantages de performances CDN).

  • Il existe également quelques scénarios marginaux comme en utilisant des images/vidéos externes avec canvas .

Ces inconvénients lors de l'accès à *- les ressources appropriées pourraient être simplement considérées comme acceptables car au moins CORS est en jeu par défaut quand cela compte le plus .

12
o.v.