J’ai récemment dû définir Access-Control-Allow-Origin
sur *
afin de pouvoir effectuer des appels ajax inter-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 le fais mal.
En répondant avec Access-Control-Allow-Origin: *
, la ressource demandée permet le partage avec chaque origine. Cela signifie que tout site peut envoyer une demande 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 quelque chose est implémenté comme un système d’authentification ou d’autorisation basé sur quelque chose qui est automatiquement fourni par le navigateur (cookies, sessions basées sur des cookies, etc.), les requêtes déclenchées par les sites tiers les utiliseront également.
Cela pose en effet un risque de 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? .
AFAIK, Access-Control-Allow-Origin est juste 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, par exemple pour 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.
La fin du serveur ne vérifie pas réellement quelle est l’origine de la requête lorsqu’elle renvoie la réponse. Il ajoute simplement l’en-tête http. C’est le navigateur (le côté client) qui a envoyé la requête qui décide de lire l’en-tête de contrôle d’access et d’y donner suite. Notez que dans le cas de XHR, il peut utiliser une requête 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 entier, peu importe ce qui y est défini.
Voir aussi Problèmes de sécurité possibles lors de la définition 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 quelques «vecteurs d’attaque» supplémentaires avec lesquels vous pouvez jouer, par exemple, en utilisant des navigateurs Web standard qui respectent cet en-tête HTTP.
Voici 2 exemples affichés en tant que commentaires, lorsqu’un joker est vraiment problématique:
Supposons que je me connecte au site Web de ma banque. Si je vais sur une autre page et que je retourne ensuite dans ma banque, je suis toujours connecté à cause d’un cookie. Les autres utilisateurs sur Internet peuvent accéder aux mêmes URL que moi dans 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 emprunter l’identité de l’utilisateur.
– Brad
Supposons que vous ayez un routeur domestique commun, tel qu’un Linksys WRT54g ou quelque chose du genre. Supposons que ce routeur autorise les requêtes d’origine croisée. Un script sur ma page Web pourrait transformer les requêtes HTTP en adresses IP de routeur 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 noeud DDoS. (La plupart des routeurs ont des pages de test qui autorisent les pings ou de simples vérifications de serveur HTTP. Celles-ci peuvent être utilisées en masse.)
– Brad
Je pense que ces commentaires auraient dû être des réponses, car ils expliquent le problème avec un exemple réel.