Quels sont les risques de sécurité liés à la configuration de Access-Control-Allow-Origin?
J'ai récemment dû définir Access-Control-Allow-Origin à * afin de pouvoir effectuer des appels ajax entre sous-domaines.
Maintenant, je ne peux pas m'empêcher de penser que je mets mon environnement en danger.
S'il vous plaît, aidez-moi si je me trompe.
En répondant avec Access-Control-Allow-Origin: *, la ressource demandée permet le partage avec chaque origine. Cela signifie en gros 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 sur votre site au nom de ses visiteurs et traiter sa réponse. Si vous avez mis en œuvre un système d'authentification ou d'autorisation basé sur un élément fourni automatiquement par le navigateur (cookies, sessions basées sur des cookies, etc.), les requêtes déclenchées par les sites tiers les utilisent également.
Cela pose effectivement un risque pour la sécurité, en particulier si vous autorisez le partage de 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 d'activer CORS?.
Access-Control-Allow-Origin: * est totalement sûr d’ajouter à une ressource sauf si cette ressource contient des données privées protégées par autre chose que des informations d’authentification standard (cookies, autorisation de base, client TLS). certificats).
Ex: les données protégées par les cookies sont en sécurité
Imagine 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. C'est sûr d'ajouter Access-Control-Allow-Origin: * à cette ressource, car cet en-tête permet uniquement l’accès à la réponse si la demande est faite sans cookies, et les cookies sont requis pour obtenir les données privées. En conséquence, aucune donnée privée n'est divulguée.
Exemple: les données protégées par emplacement/ip/réseau interne ne sont pas sécurisées (malheureusement commun aux intranets et aux appareils domestiques):
Imagine https://intranet.example.com/company-private-data, qui expose les données de l'entreprise privée, mais vous ne pouvez y accéder que si vous êtes sur le réseau wifi de l'entreprise. C'est pas sûr d'ajouter Access-Control-Allow-Origin: * à cette ressource, car elle est protégée en utilisant autre chose que les informations d'identification standard. Sinon, un mauvais script pourrait vous utiliser comme tunnel vers l'intranet.
Règle de base
Imaginez ce qu'un utilisateur verrait s'il accédait à la ressource dans une fenêtre de navigation privée. Si tout le monde voit ce contenu (y compris le code source que le navigateur a reçu), vous pouvez ajouter Access-Control-Allow-Origin: *.
Autant que je sache, Access-Control-Allow-Origin est simplement un en-tête http envoyé du serveur au navigateur. Le limiter à une adresse spécifique (ou le désactiver) ne rend pas votre site plus sûr pour, par exemple, les robots. Si les robots le souhaitent, ils peuvent simplement ignorer l'en-tête. Les navigateurs habituels (Explorer, Chrome, etc.) respectent par défaut l'en-tête. Mais une application comme Postman l'ignore simplement.
Le serveur ne vérifie pas réellement quelle est l'origine de la requête lorsqu'il renvoie la réponse. Il ajoute simplement l'en-tête http. C'est le navigateur (l'extrémité du 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 de XHR, il peut utiliser une demande spéciale 'OPTIONS' pour demander d’abord les en-têtes.
Ainsi, toute personne ayant des capacités de script créatives peut facilement ignorer l’en-tête complet, quel que soit le contenu.
Voir aussi Problèmes de sécurité possibles liés à la configuration 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 danger.
Si quelqu'un veut vous attaquer, il peut facilement contourner Access-Control-Allow-Origin. Mais en activant "*", vous donnez à l'attaquant un peu plus de "vecteurs d'attaque" avec lesquels vous pouvez jouer, comme avec des navigateurs Web classiques qui respectent cet en-tête HTTP.
Voici 2 exemples postés sous forme de commentaires, quand un joker est vraiment problématique:
Supposons que je me connecte au site Web de ma banque. Si je vais à une autre page puis retourne à ma banque, je suis toujours connecté à cause d'un cookie. Les autres utilisateurs d’Internet peuvent utiliser les mêmes adresses URL que ma banque, mais ils ne pourront pas accéder à mon compte sans le cookie. Si les demandes d'origine croisée sont autorisées, un site Web malveillant peut effectivement emprunter l'identité de l'utilisateur.
- Brad
Supposons que vous ayez un routeur domestique commun, tel qu'un Linksys WRT54g ou autre. Supposons que le routeur autorise les requêtes inter-origines. Un script sur ma page Web peut envoyer des requêtes HTTP aux adresses IP de routeurs communes (telles que 192.168.1.1) et reconfigurer votre routeur pour autoriser les attaques. Il peut même utiliser votre routeur directement en tant que nœud DDoS. (La plupart des routeurs ont des pages de test qui autorisent des pings ou de simples vérifications de serveur HTTP. Celles-ci peuvent faire l'objet d'abus massifs.)
- Brad
Je pense que ces commentaires auraient dû être des réponses, car ils expliquent le problème avec un exemple concret.