J'ai récemment dû configurer Access-Control-Allow-Originpour *pouvoir effectuer des appels ajax entre sous-domaines.
Maintenant, je ne peux pas m'empêcher de penser que je mets mon environnement à des risques de sécurité.
S'il vous plaît, aidez-moi si je fais mal.

En répondant avec Access-Control-Allow-Origin: *, la ressource demandée permet le partage 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 œuvre quelque chose 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 demandes 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 certaines ressources mais pour chaque ressource. Dans ce contexte, vous devriez jeter un œil à Quand est-il sûr d'activer CORS? .

Access-Control-Allow-Origin: *peut être ajouté en toute sécurité à 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 (cookies, authentification de base, certificats clients TLS).

Par exemple: les données protégées par les cookies sont en sécurité

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 est prudent d'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. En conséquence, aucune donnée privée n'est divulguée.

Par exemple: les données protégées par emplacement / ip / réseau interne ne sont pas sûres (malheureusement courantes avec les intranets et les appareils ménagers):

Imaginez https://intranet.example.com/company-private-data, qui expose les données de l'entreprise privée, mais cela n'est accessible que si vous êtes sur le réseau wifi de l'entreprise. Il n'est pas sûr d'ajouter Access-Control-Allow-Origin: *à cette ressource, car elle est protégée par 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 vous êtes satisfait que tout le monde voit ce contenu (y compris le code source reçu par le navigateur), vous pouvez l'ajouter en toute sécurité Access-Control-Allow-Origin: *.

AFAIK, Access-Control-Allow-Origin est juste un en-tête http envoyé du serveur au navigateur. Le limiter à une adresse spécifique (ou la 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 tout simplement.

L'extrémité du serveur ne vérifie pas réellement l'origine de la requête lorsqu'elle renvoie la réponse. Il ajoute simplement l'en-tête http. C'est le navigateur (côté client) qui a envoyé la requête 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 requête spéciale 'OPTIONS' pour demander les en-têtes en premier.

Ainsi, toute personne ayant des capacités de création de scripts peut facilement ignorer l'en-tête entier, quel que soit celui qui y est défini.

Voir aussi Problèmes de sécurité possibles liés à la configuration d'Access-Control-Allow-Origin .

Maintenant pour répondre à la question

Je ne peux pas m'empêcher de penser que je mets mon environnement à des risques de sécurité.

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 jouer, par exemple en utilisant des navigateurs Web normaux qui honorent cet en-tête HTTP.

Voici 2 exemples publiés sous forme de commentaires, lorsqu'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 et que je retourne ensuite dans ma banque, je suis toujours connecté à cause d'un cookie. D'autres utilisateurs sur Internet peuvent accéder aux mêmes URL à ma banque que moi, 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 se faire passer pour 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 cross-origin. Un script sur ma page Web pourrait envoyer des requêtes HTTP aux adresses IP communes du routeur (comme 192.168.1.1) et reconfigurer votre routeur pour autoriser les attaques. Il peut même utiliser votre routeur directement comme nœud DDoS. (La plupart des routeurs ont des pages de test qui permettent des pings ou de simples vérifications de serveur HTTP. Celles-ci peuvent être abusées en masse.)

- Brad

Je pense que ces commentaires auraient dû être des réponses, car ils expliquent le problème avec un exemple concret.

Dans le scénario où le serveur tente de désactiver complètement le CORS en définissant les en-têtes ci-dessous.

• Access-Control-Allow-Origin: * (indique au navigateur que le serveur accepte les requêtes intersites de toute ORIGINE)

• Access-Control-Allow-Credentials: true (indique au navigateur que les requêtes intersites peuvent envoyer des cookies)

Il y a une sécurité intégrée implémentée dans les navigateurs qui entraînera une erreur ci-dessous

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

Ainsi, dans la plupart des scénarios, définir «Access-Control-Allow-Origin» sur *ne sera pas un problème. Cependant, pour se protéger contre les attaques, le serveur peut maintenir une liste des origines autorisées et chaque fois que le serveur reçoit une demande d'origine croisée, il peut valider l'en-tête ORIGIN par rapport à la liste des origines autorisées, puis renvoyer la même chose dans Access-Control-Allow-Origin entête.

Étant donné que l'en-tête ORIGIN ne peut pas être modifié par javascript exécuté sur le navigateur, le site malveillant ne pourra pas l'usurper.