J'ai récemment dû régler Access-Control-Allow-Origin a * afin de pouvoir effectuer des appels AJAX inter-sous-domaines. J'ai l'impression que cela pourrait poser un problème de sécurité. Quels sont les risques auxquels je m'expose si je conserve ce paramètre ?
Réponses
Trop de publicités?
Gumbo
Points
279147
En répondant par Access-Control-Allow-Origin: * la ressource demandée peut être partagée avec toutes les origines. Cela signifie essentiellement que n'importe quel site peut envoyer une requête XHR à votre site et accéder à la réponse du serveur, ce qui ne serait pas le cas si vous n'aviez pas implémenté cette réponse CORS.
Ainsi, tout site peut faire une demande à votre site au nom de ses visiteurs et traiter sa réponse. Si vous avez mis en place un système d'authentification ou d'autorisation basé sur un élément fourni automatiquement par le navigateur (cookies, sessions basées sur les cookies, etc.), les demandes déclenchées par les sites tiers l'utiliseront également.
Cela pose en effet un risque de sécurité, en particulier si vous autorisez le partage des ressources non seulement pour les ressources sélectionnées mais pour toutes les ressources. Dans ce contexte, vous devriez jeter un coup d'œil à Quand est-il prudent d'activer CORS ? .
Mise à jour (2020-10-07)
Actuel Standard Fetch omet les informations d'identification lorsque le mode d'identification est défini comme suit include si Access-Control-Allow-Origin est réglé sur * .
Par conséquent, si vous utilisez une authentification basée sur un cookie, vos informations d'identification ne seront pas envoyées lors de la demande.
Access-Control-Allow-Origin: * est totalement sûr à ajouter à n'importe quelle ressource, sauf si cette ressource contient des données privées protégées par autre chose que des informations d'identification standard. Les informations d'identification standard sont les cookies, l'authentification de base HTTP et les certificats client TLS.
Eg : Les données protégées par les cookies sont sûres
Imaginez https://example.com/users-private-data qui peut exposer des données privées en fonction de l'état de connexion de l'utilisateur. Cet état utilise un cookie de session. Il s'agit sûr à ajouter Access-Control-Allow-Origin: * à cette ressource, car cet en-tête ne permet d'accéder à la réponse que si la demande est effectuée sans cookies, et les cookies sont nécessaires pour obtenir les données privées. Par conséquent, aucune donnée privée n'est divulguée.
Par exemple, les données protégées par l'emplacement, l'adresse IP ou le réseau interne ne sont pas sûres (ce qui est malheureusement fréquent avec les intranets et les appareils domestiques) :
Imaginez https://intranet.example.com/company-private-data qui expose les données privées de l'entreprise, mais celles-ci ne sont accessibles que si vous vous trouvez sur le réseau wifi de l'entreprise. C'est pas sûr à ajouter Access-Control-Allow-Origin: * à cette ressource, car elle est protégée par un système autre que les informations d'identification standard. Sinon, un mauvais script pourrait vous utiliser comme tunnel vers l'intranet.
Règle d'or
Imaginez ce qu'un utilisateur verrait s'il accédait à la ressource dans une fenêtre incognito. Si vous êtes satisfait du fait que tout le monde puisse voir ce contenu (y compris le code source que le navigateur a reçu), il est possible d'ajouter l'option Access-Control-Allow-Origin: * .
commonpike
Points
1779
À ma connaissance, Access-Control-Allow-Origin est simplement un en-tête http envoyé par le serveur au navigateur. Le fait de le limiter à une adresse spécifique (ou de le désactiver) ne rend pas votre site plus sûr pour les robots, par exemple. Si les robots le souhaitent, ils peuvent tout simplement ignorer l'en-tête. Les navigateurs classiques (Explorer, Chrome, etc.) respectent par défaut l'en-tête. Mais une application comme Facteur l'ignore tout simplement.
Le serveur ne vérifie pas réellement l'origine de la demande lorsqu'il renvoie la réponse. Il ajoute simplement l'en-tête http. C'est le navigateur (le client) qui a envoyé la demande qui décide de lire l'en-tête de contrôle d'accès et d'agir en conséquence. Notez que dans le cas du XHR, il peut utiliser une requête spéciale "OPTIONS" pour demander les en-têtes en premier.
Ainsi, toute personne disposant de capacités de script créatives peut facilement ignorer l'ensemble de l'en-tête, quel que soit le contenu de celui-ci.
Voir aussi Problèmes de sécurité possibles liés au paramétrage de Access-Control-Allow-Origin .
Maintenant, pour répondre à la question
Je ne peux pas m'empêcher de penser que je mets mon environnement en sécurité. risques.
Si quelqu'un veut vous attaquer, il peut facilement contourner le contrôle d'accès autorisant l'origine (Access-Control-Allow-Origin). Mais en activant "*", vous donnez à l'attaquant quelques "vecteurs d'attaque" supplémentaires, comme l'utilisation de navigateurs ordinaires qui respectent cet en-tête HTTP.
Christian Gollhardt
Points
2103
Voici deux exemples postés en commentaires, où un caractère générique est vraiment problématique :
Supposons que je me connecte au site web de ma banque. Si je vais sur une autre page, puis revenir à ma banque, je suis toujours connecté grâce à un cookie. D'autres Les autres utilisateurs d'Internet peuvent consulter les mêmes URL que moi sur le site de ma banque. ils ne seront pas en mesure d'accéder à mon compte sans le cookie. Si les requêtes d'origine croisée sont autorisées, un site web malveillant peut effectivement usurper l'identité de l'utilisateur.
- Brad
Supposons que vous ayez un routeur domestique commun, tel qu'un Linksys WRT54g ou un Linksys WRT54g. ou autre. Supposons que ce routeur autorise les requêtes d'origine croisée. Un script sur ma page web pourrait faire des requêtes HTTP vers des adresses IP de routeurs communs (comme 192.168.1.1) et reconfigurer votre routeur pour permettre des attaques. Il peut même utiliser votre routeur directement comme un nœud DDoS. (La plupart des routeurs ont pages de test qui permettent d'effectuer des pings ou de simples vérifications du serveur HTTP. Ces peuvent être abusés en masse).
- Brad
Je pense que ces commentaires auraient dû être des réponses, car ils expliquent le problème avec un exemple concret.
Yuu
Points
479
*Cette réponse a été écrite à l'origine comme une réponse à [`What are the security implications of setting Access-Control-Allow-Headers: , if any?`](https://webcache.googleusercontent.com/search?q=cache:ZGzhqnAL9IIJ:https://stackoverflow.com/a/69304711/4420129) et a été fusionné bien qu'il ne soit pas pertinent pour cette question.**
Pour le paramétrer en tant que joker * signifie que tous les en-têtes sont autorisés, à l'exception de ceux qui sont sur la liste de sécurité et de supprimer les restrictions qui les protègent.
Ce sont les restrictions pour que les 4 en-têtes de la liste sécurisée soient considérés comme sûrs :
- Pour Accept-Language et Content-Language : ne peut avoir que des valeurs composées de
0-9,A-Z,a-zl'espace ou*,-.;=.- Pour Accept et Content-Type : ne peut pas contenir un octet d'en-tête de requête CORS-unsafe :
0x00-0x1F(sauf pour0x09(HT), ce qui est autorisé),"():<>?@[\]{}et0x7F(DEL).- Pour Content-Type : doit avoir un type MIME de sa valeur analysée (en ignorant les paramètres) de soit
application/x-www-form-urlencoded,multipart/form-dataoutext/plain.- Pour tout en-tête : la longueur de la valeur ne peut pas être supérieure à 128.
Pour des raisons de simplicité, je vais baser ma réponse sur ces en-têtes.
Selon l'implémentation du serveur, la simple suppression de ces limitations peut être très dangereuse (pour l'utilisateur).
Par exemple, ce plugin wordpress obsolète présente une vulnérabilité XSS réfléchie dans laquelle la valeur du paramètre Accept-Language était analysé et rendu tel quel sur la page, provoquant l'exécution de script sur le navigateur de l'utilisateur si une charge utile malveillante était incluse dans la valeur.
Avec l'en-tête joker Access-Control-Allow-Headers: * un site tiers redirigeant vers votre site pourrait définir la valeur de l'en-tête comme suit Accept Language: <script src="https://example.com/malicious-script.js"></script> étant donné que le caractère générique supprime la restriction du point 1 ci-dessus.
La réponse de contrôle préalable donne alors le feu vert à cette demande, et l'utilisateur est redirigé vers votre site, déclenchant un XSS sur son navigateur, dont l'impact peut aller d'une popup ennuyeuse à la perte de contrôle de son compte par le détournement de cookie.
Je vous déconseille donc fortement de définir un caractère générique, sauf s'il s'agit d'un point de terminaison d'API pour lequel rien n'est rendu sur la page.
Vous pouvez définir Access-Control-Allow-Headers: Pragma comme une solution alternative à votre problème.
Notez que la valeur * ne compte comme une valeur spéciale de type joker que pour les demandes sans justificatifs (demandes sans cookies HTTP ou informations d'authentification HTTP), sinon elle sera lue comme un en-tête littéral. Documentation
- Réponses précédentes
- Plus de réponses
