Comment CORS empêche-t-il XSS?
J'ai récemment entendu parler de CORS et j'ai eu l'impression que son but est de empêcher XSS . Avec CORS, le navigateur bloque les demandes vers différents domaines, sauf si des en-têtes particuliers sont en place.
Mais si une personne malveillante injecte du JavaScript dans une page pour voler les cookies des utilisateurs et les envoyer à une URL qu'il contrôle, il lui suffit d'ajouter l'en-tête suivant côté serveur pour que la demande fonctionne de toute façon:
Access-Control-Allow-Origin: *
Alors, comment CORS empêche-t-il XSS? Ou ai-je mal compris l'objectif de CORS, et cela n'a tout simplement rien à voir avec XSS en soi?
TL; DR: Comment CORS empêche-t-il XSS? Ce n'est pas le cas. Ce n'est pas censé le faire.
CORS est destiné à permettre aux hôtes de ressources (tout service qui rend ses données disponibles via HTTP) de restreindre les sites Web qui peuvent accéder à ces données.
Exemple: Vous hébergez un site Web qui affiche les données de trafic et vous utilisez AJAX requêtes sur votre site Web. Si SOP et CORS n'étaient pas là, n'importe quel autre site Web pouvait afficher vos données de trafic simplement AJAXing à vos points de terminaison, n'importe qui pouvait facilement "voler" vos données et donc vos utilisateurs et votre argent.
Dans certains cas, le partage des données ( C ross O rigin R esource S haring) est destiné, par exemple lors de l'affichage des likes et des trucs de l'API Facebook sur votre page Web. Il suffit de supprimer SOP pour accomplir cela est une mauvaise idée pour les raisons expliquées dans le paragraphe ci-dessus. Donc CORS a été introduit.
CORS n'est pas lié à XSS car tout attaquant qui peut placer un élément malveillant de JavaScript dans un site Web peut également configurer un serveur qui envoie les en-têtes CORS corrects. CORS ne peut pas empêcher JavaScript malveillant d'envoyer des identifiants de session et des cookies permlogin à l'attaquant.
Cross-Site-Scripting (XSS) est l'exécution du code de script défini par l'attaquant dans le contexte d'un autre site. CORS n'empêche pas XSS, en fait il n'est pas lié à XSS.
Au lieu de cela, CORS offre un moyen d'affaiblir les restrictions existantes sur les demandes Ajax (c'est-à-dire XMLHTTPRequest) d'une manière qui, espérons-le, n'introduit pas plus de problèmes de sécurité. Traditionnellement, XMLHTTPRequest était limité à communiquer au sein de la même origine, c'est-à-dire qu'il n'était pas possible d'envoyer une demande à un site externe. Cette restriction a été effectuée afin qu'un attaquant ne puisse pas effectuer une demande intersite et obtenir le résultat de la demande, car cela permettrait à un attaquant de lire les données des sites sur lesquels les utilisateurs étaient connectés (car des sessions et d'autres cookies sont envoyés avec chacun demande à un site).
Avec CORS, cette restriction est partiellement supprimée. Il est désormais possible d'envoyer une requête XMLHTTPRequest à un autre site mais le résultat ne peut être lu à l'intérieur de l'application que si le site distant a explicitement ajouté des en-têtes CORS qui autorisent l'accès. Mais encore une fois, ce n'est pas l'exécution de script sur le site distant et donc cela n'est pas lié à XSS.
D'autres réponses sont exactes que XSS et CORS ne sont pas directement liés (bien que CORS puisse aider à limiter l'impact de XSS sur le site vulnérable).
Fondamentalement, CORS permet au code frontal de votre site Web js d'accéder à votre site Web avec les cookies et les informations d'identification saisies dans votre navigateur tandis que votre backend reste protégé contre les js d'autres sites, demandant au navigateur client d'y accéder (avec les informations d'identification que l'utilisateur a obtenues).
Lorsque cela est Control-Allow-Credentials: true est défini (qui permet au navigateur d'envoyer des cookies et l'authentification de base/gssapi/napi). Je ne sais toujours pas comment CORS aide sans cette option. Voir ma question " dois-je restreindre Origin dans une application API? "
CORS ne protège rien, SOP (même politique d'origine) protège quelque chose à la place. SOP protège le domaine cible et navigateur utilisateur .
En fait, CORS affaiblit les restrictions existantes de SOP pour aider les développeurs de sites Web à utiliser des données partagées d'autres origines.
CORS et XSS sont liés, mais pas directement. La meilleure façon de l'expliquer est par exemple: nous considérerons 3 serveurs (your_bank.com, api.your_bank.com, badguy.com *) et 1 client (votre navigateur).
- Vous êtes connecté à your_bank.com (votre navigateur contient des cookies d'authentification).
- Your_bank.com effectue des transactions en envoyant AJAX demandes à api.your_bank.com en utilisant encore plus de cookies (conservés dans le navigateur). Normalement, votre navigateur SOP bloquerait cette demande, mais à la place CORS (accordé par api.your_bank.com) le permet.
- Vous voyez quelque chose de brillant sur badguy.com et visitez cette page.
- Badguy.com tente des transactions en envoyant AJAX demandes à api.your_bank.com en utilisant les cookies pour ce domaine détenus dans votre navigateur.
À l'étape 4, votre navigateur (qui n'est pas compromis) possède l'en-tête "Origin" envoyé à api.your_bank.com. Si CORS est correctement configuré, cette étape sera bloquée. Votre navigateur, en tant que propriétaire des cookies et des en-têtes de demande, assure l'accès aux autres sites.
* Le site badguy.com peut être légitime, mais souffre d'un problème XSS.