Quels sont les risques pour la sécurité de paramètre Access-Control-Allow-Origin?

J'ai récemment eu à définir Access-Control-Allow-Origin à * afin d'être en mesure de faire des sous-domaine des appels ajax.

Maintenant, je ne peux pas aider mais sentir que je suis en train de mettre mon environnement à des risques de sécurité.

S'il vous plaît aidez-moi si je me fais mal.

InformationsquelleAutor Hamed Momeni | 2012-08-17
  1. 51

    En répondant avec Access-Control-Allow-Origin: *, la ressource demandée permet de partager avec toutes origines. Cela signifie essentiellement que tout site peut envoyer une demande XHR pour votre site et d'accéder à la réponse du serveur qui ne serait pas le cas si vous n'aviez pas mis en œuvre cette réponse de la SCRO.

    De sorte que tout site peut faire une demande à votre site pour le compte de leurs visiteurs et les processus de sa réponse. Si vous avez quelque chose de mis en œuvre comme une authentification ou régime d'autorisation qui est basé sur quelque chose qui est fourni automatiquement par le navigateur (cookies, les cookies de sessions, etc.), les demandes déclenchée par les sites de tiers qui utilisent eux aussi.

    Cela pose un risque pour la sécurité, en particulier si vous autorisez le partage des ressources non seulement pour les ressources sélectionnées, mais pour chaque ressource. Dans ce contexte, vous devriez jeter un oeil à Quand est-il sécuritaire pour permettre la SCRO?.

    • Si vous pouvez donner un exemple précis de la façon dont l'partagé auth l'accès pose un risque pour la sécurité, je vais upvote ce.
    • Quid du contenu statique? (par exemple, statique cdn de contenu, tels que les scripts javascript, css, statique format html, etc.) Existe-il des problèmes de sécurité de la mise Access-Control-Allow-Origin: * sur eux? Il n'y aura pas nogin etc, ils sont publics pour tout le monde?
    • C'est ok.
    • En fait, cette réponse n'est pas tout à fait correct selon le courant de la SCRO standard: "La chaîne de caractères '*' ne peut pas être utilisé pour une ressource qui prend en charge les informations d'identification." Si vous ne pouvez pas forcer une demande d'utilisation transitoire de l'authentification dans la forme de cookies, le cache HTTP authentification ou un client de certificats SSL. Toutefois, si le site web a été par exemple utiliser le stockage local pour l'authentification, ce serait un problème.
    • N'hésitez pas à corriger ma réponse.
    • Eh bien, je ne suis pas sûr au sujet des implications de Access-Control-Allow-Origin: * moi-même, c'est pourquoi je cherchais à ce Q&A. I. e. Je ne sais pas quelle était la bonne réponse, mais je serais intéressé
    • J'ai essayé ce scénario et Chrome ne suivez de la SCRO standard comme vous l'avez mentionné. par exemple, la chaîne "" n'est pas pris en charge avec les informations d'identification de la demande. Voici ce qui est rapporté par Chrome: "XMLHttpRequest ne peut pas charger localhost:12346/hello. Un caractère '' ne peut pas être utilisée dans l '"Access-Control-Allow-Origin' en-tête lorsque les informations d'identification indicateur est vrai. Origine 'localhost:12345' est donc pas autorisé à accéder. Les informations d'identification du mode de XMLHttpRequest est contrôlée par le withCredentials attribut."
    • une correction ajoutée mentionné ci-dessus, mettre aussi une solution de rechange génériques pour certains cas d'utilisation qui peut être d'moteurs de recherche
    • Ceci ne répond pas à la question. "Cela pose un risque pour la sécurité, en particulier si vous autorisez le partage des ressources non seulement pour les ressources sélectionnées, mais pour toutes les ressources." Quel est le risque?...est ce que l'op a demandé.
    • C'est certainement un risque pour la sécurité blog.portswigger.net/2016/10/... et youtube.com/watch?v=wgkj4ZgxI4c

    InformationsquelleAutor Gumbo
  2. 24

    Access-Control-Allow-Origin: * est totalement sûr à ajouter à n'importe quelle ressource, sauf cette ressource contient des données privées protégées par quelque chose d'autre que les identifiants de connexion (cookies, basic auth TLS certificats client).

    Par exemple: les Données protégées par des cookies est sûr

    Imaginer https://example.com/users-private-data, ce qui peut exposer des données privées en fonction de l'utilisateur connecté dans l'état. Cet état utilise un cookie de session. C'est sûr pour ajouter Access-Control-Allow-Origin: * à cette ressource, que cet en-tête permet uniquement l'accès à la réponse, si la demande est faite sans les cookies et les cookies sont nécessaires pour obtenir les données privées. Comme un résultat, pas de données personnelles est une fuite.

    Par exemple: les Données protégées par emplacement /ip /réseau interne n'est pas sûr (malheureusement fréquentes avec les intranets et les appareils ménagers):

    Imaginer https://intranet.example.com/company-private-data, ce qui expose les données privées de la société, mais ce ne peut être accessible que si vous êtes sur la société du réseau wifi. C'est pas sûr pour ajouter Access-Control-Allow-Origin: * à cette ressource, car il est protégé à l'aide de quelque chose d'autre que les informations d'identification. Sinon, un mauvais script pourrait vous utiliser comme un tunnel à l'intranet.

    Règle de pouce

    Imaginer ce qu'un utilisateur de voir si elles ont eu accès à la ressource dans une fenêtre de navigation privée. Si vous êtes heureux avec tout le monde de voir ce contenu (y compris le code source du navigateur reçu), il est sûr d'ajouter Access-Control-Allow-Origin: *.

    • devrait ", car il ne permet de demandes sans cookies" être ", comme on l'autorise seulement des requêtes avec les cookies"?
    • pas de. Access-Control-Allow-Origin: * autorise seulement des requêtes sans cookies. J'ai édité la réponse de clarifier un peu.
    InformationsquelleAutor JaffaTheCake
  3. 8

    Autant que je sache, Access-Control-Allow-Origin est juste un en-tête http envoyé par le serveur au navigateur. La limiter à une adresse spécifique (ou le désactiver) ne permet pas de rendre votre site plus sûr pour, par exemple, des robots. Si les robots veulent, ils peuvent simplement ignorer l'en-tête. Le régulier navigateurs (Explorer, Chrome, etc.) par défaut, l'honneur de l'en-tête. Mais une application comme Facteur simplement les ignorer.

    La fin du serveur n'est pas réellement vérifier ce que l' 'origine-est de la demande lorsqu'il renvoie la réponse. Il ajoute juste l'en-tête http. C'est le navigateur (le client final), qui a envoyé la demande qui décide de lire l'accès en-tête de contrôle et d'agir sur elle. Notez que dans le cas de XHR il peut utiliser un spécial "OPTIONS" demande de poser pour les en-têtes de premier.

    Donc, n'importe qui avec creative script capacités peuvent facilement ignorer l'ensemble de la tête, tout ce qui est mis en elle.

    Voir aussi D'éventuels problèmes de sécurité de paramètre Access-Control-Allow-Origin.

    Maintenant pour répondre à la question

    Je ne peux pas aider mais sentir que je suis en train de mettre mon environnement de sécurité
    risques.

    Si quelqu'un veut vous attaquer, ils peuvent facilement contourner les Access-Control-Allow-Origin. Mais en permettant '*' vous faire donner à l'attaquant un peu plus de " vecteurs d'attaque pour jouer avec, comme, l'utilisation de navigateurs internet, que l'honneur que l'en-tête HTTP.

    • Regardez ce qui, du point de vue d'un imprudents de l'utilisateur final. Quelqu'un peut configurer une page web malveillante qui injecte JavaScript pour transmettre les données entre le vrai site et un site malveillant (disons qu'ils ne veulent voler votre mot de passe). La fin navigateur web de l'utilisateur sera normalement bloquer cette croix communication de site, mais si l'Access-Control-Allow-Origin est définie, alors il sera permis, et l'utilisateur final n'est pas plus sage.
    • Oui, réglage Access-Control-Allow-Origin * sur un site web malveillant qui héberge des scripts pour voler des mots de passe est fortement déconseillée 🙂
    • Oh, j'en ai un downvote pour la blague. Non, je ne peux pas la regarder d'un point de vue utilisateur. C'est le webmaster, ou sitebuilder, qui décide de l'en-tête HTTP. Someone can set up a malicious webpage - oui, et que quelqu'un va ajouter de la méchante de la directive, trop. Et encore, pour le client comme un infecté webbrowser - peut choisir d'ignorer les en-têtes http de tout ce qui est en eux.
    • J'obtiens toujours downvotes. Si quelqu'un veut downvote, veuillez expliquer pourquoi ?
    • Vous avez raison en ce que quelqu'un pourrait faire un script pour juste totalement ignorer l'en-tête. Si les données sont accessibles, il est accessible avec ou sans les en-têtes de la SCRO. Il y a un autre vecteur d'attaque vous n'êtes pas tenu bien. Supposons que je me connecte sur mon site internet de la banque. Si je vais sur une autre page, puis de revenir à ma banque, je suis toujours connecté en raison d'un cookie. D'autres utilisateurs sur l'internet peut frapper la même Url à ma banque que je fais, mais ils ne seront pas en mesure d'accéder à mon compte sans le cookie. Si les requêtes d'origine sont autorisés, un site web malveillant peut effectivement usurper l'identité...
    • l'utilisateur. Mettre une autre manière, vous pouvez simplement visiter mon site (qui pourrait même être un site normal, avec rien suspectes... peut-être que c'est un vrai site de pièce de théâtre qui vient d'être piraté!) mais un peu de JavaScript qui envoie des requêtes HTTP à votre banque de transférer des fonds de mon compte. La banque ne sait pas la différence entre les demandes de ses pages ou de demandes en provenance d'autres pages. Les deux ont le cookie permettant à la demande pour réussir.
    • Laissez-moi vous donner un exemple plus courant... celui qui arrive tout le temps. Supposons que vous avez une maison commune routeur, tels que un routeur Linksys WRT54g ou quelque chose. Supposons que le routeur permet à la croix-de l'origine des demandes. Un script sur ma page web pourrait faire des requêtes HTTP à la commune des adresses IP du routeur (comme 192.168.1.1) et de reconfigurer votre routeur pour permettre à des attaques. Il peut même utiliser votre routeur directement comme un DDoS nœud. (La plupart des routeurs ont des pages de test qui permettent de pings ou simple serveur HTTP contrôles. Ceux-ci peuvent être victimes de violence en masse.)
    • En ne permettant pas à la croix-de l'origine des demandes, vous pouvez effectivement mettre un mur entre deux sites différents peuvent accéder à partir du même navigateur. Il empêche un site d'accéder aux données d'une autre, de l'identification de l'utilisateur qui peuvent avoir déjà connecté.
    • merci pour les commentaires détaillés. Une banque et un routeur en sont de bons exemples de sites qui vraiment ne veulent pas de la croix-requêtes d'origine (bien que le cookie exemple l'habitude de travailler avec Access-Control-Allow-Origin *). Ce que le nom d'en-tête n'est pas claire, c'est que sa en fait un mécanisme de sécurité, qui rend des sons beaucoup plus forte (ou plus dangereux) que c'est vraiment.
    • Les Cookies ne de travail. quickleft.com/blog/cookies-with-my-cors
    • mais "La chaîne de caractères '*' ne peut pas être utilisé pour une ressource qui prend en charge les informations d'identification." w3.org/TR/cors/#resource-requests. De façon plus spécifique Access-Control-Allow-Origin url de travail.
    • C'est une non-réponse. Op interroge sur les implications de sécurité de l'activation de la SCRO pour tous les domaines. Cette réponse n'en fournit pas.

    InformationsquelleAutor commonpike
  4. 5

    Voici 2 exemples posté des commentaires, quand un générique est vraiment problématique:

    Suppose que je me suis connecter sur mon site internet de la banque. Si je vais sur une autre page, puis
    de revenir à ma banque, je suis toujours connecté en raison d'un cookie. D'autres
    les utilisateurs sur l'internet peut frapper la même Url à ma banque que je fais, encore
    ils ne seront pas en mesure d'accéder à mon compte sans le cookie. Si
    cross-origin les demandes sont autorisées, un site web malveillant peut effectivement
    emprunter l'identité de l'utilisateur.

    – Brad

    Supposons que vous avez une maison commune routeur, tels que un routeur Linksys WRT54g ou
    quelque chose. Supposons que le routeur permet à la croix-de l'origine des demandes. Un script
    sur ma page web pourrait faire des requêtes HTTP à la commune des adresses IP du routeur
    (comme 192.168.1.1) et de reconfigurer votre routeur pour permettre à des attaques. Il
    pouvez même utiliser votre routeur directement comme un DDoS nœud. (La plupart des routeurs ont
    des pages de test qui permettent de pings ou simple serveur HTTP contrôles. Ces
    peut être abusé en masse.)

    – Brad

    J'ai l'impression que ces commentaires doivent avoir été des réponses, parce qu'ils expliquer le problème avec un exemple réel.

    • Sauf cela ne fonctionne pas. "La chaîne de caractères '*' ne peut pas être utilisé pour une ressource qui prend en charge les informations d'identification." w3.org/TR/cors/#resource-requests
    • Comment fonctionne le navigateur de distinguer entre les pages qui nécessitent une authentification et ceux avec d'autres données dans les en-têtes?
    • Après avoir lu le lien fourni, il y a "prend en charge les informations d'identification du pavillon" ce qui est utilisé pour ce but. Il semble être réglé manuellement, donc on peut supposer que si quelqu'un ne savais pas comment mettre en place la SCRO correctement, ils pourraient obtenir ce drapeau de mal que de bien, donc je crois que ce qui précède vulnérabilités sont possibles.
    • L'indicateur est défini par celui qui en fait la demande. De toute façon, les scénarios ci-dessus sont des exemples d'attaques CSRF. En permettant à l' '*' origine ne sera pas vous rendre plus vulnérable alors que vous êtes déjà (peut-être un peu dans de rares cas). Dans la plupart des cas, vous pouvez faire la malicous cross-site request à l'aide de formulaires de la SCRO n'a pas d'importance. Dans le cas où vous avez besoin de faire une requête AJAX, pré-vol demandes viennent de la manière (c'est le point où le navigateur vient quand ACAO: '*' et Access-Control-Allow-Pouvoirs: 'true').
    InformationsquelleAutor