CORS aide-t-il de toute façon contre la contrefaçon intersite?
J'ai lu au cours des derniers jours sur CORS et dans de nombreux endroits, il est mentionné car il s'agit d'une fonctionnalité de "sécurité" pour aider le monde contre la contrefaçon interdomaine.
Je ne vois toujours pas l'avantage et le raisonnement de CORS. Ok, les navigateurs feront une demande de contrôle en amont/le serveur validera l'origine. Mais un attaquant peut facilement créer un HttpRequest de haut en bas avec les en-têtes (origine) qu'il souhaite et il aura accès à la ressource.
Comment CORS aide-t-il et quel en est l'avantage?
Je vais commencer ma réponse en disant que beaucoup de gens comprennent mal la même politique d'origine et ce que CORS apporte à la table.
Certaines des réponses votées déjà ici indiquent que la même politique d'origine empêche les demandes intersites et empêche donc CSRF . Ce n'est pas le cas. Tout ce que SOP fait est d'empêcher la réponse d'être lue par un autre domaine (aka Origin). Cela n'a pas d'importance si une attaque CSRF réussit ou non.
La seule fois où le SOP entre en jeu avec CSRF est d'empêcher la lecture d'un jeton par un domaine différent.
Tout ce que fait CORS, c'est détendre le SOP quand il est actif. Il n'augmente pas la sécurité, il autorise simplement des exceptions. Certains navigateurs avec un support partiel de CORS permettent les demandes XHR intersites (par exemple IE 10 et versions antérieures), mais elles ne permettent pas d’ajouter des en-têtes personnalisés. Dans les navigateurs pris en charge par CORS, l’en-tête Origin ne peut pas être défini, empêchant l'attaquant d'usurper cela.
J'ai mentionné que les domaines étaient d'origines différentes. Les origines peuvent également différer par port et protocole lorsque l'on parle de AJAX (pas tellement avec les cookies).
Enfin, tout ce qui précède n'a rien à voir avec les demandes falsifiées provenant directement d'un attaquant, par exemple avec curl. N'oubliez pas que l'attaquant doit utiliser le navigateur de la victime pour son attaque. Ils ont besoin du navigateur pour envoyer automatiquement ses cookies. Ceci ne peut pas être réalisé par une demande de curl directe car cela ne ferait qu'authentifier l'attaquant dans ce type de scénario d'attaque (la catégorie appelée "attaques côté client").
L'avantage de CORS est qu'il permet à votre domaine d'autoriser les lectures à partir d'un autre domaine approuvé. Donc, si vous avez http://data.example.org vous pouvez définir des en-têtes de réponse pour autoriser http://site.example.com pour effectuer AJAX requêtes et récupérer les données de votre API.
Vous mélangez les choses. CORS n'est pas destiné à protéger votre application contre les requêtes http conçues, il est destiné à vous protéger contre un certain type d'attaques qui "volent" les cookies ou les jetons d'accès de l'utilisateur, en vérifiant quels sites peuvent accéder à votre ressource .
Il est principalement utilisé pour protéger votre serveur/application contre la falsification de demandes intersites, où un site malveillant fera une demande au nom de l'utilisateur, éventuellement avec des intentions malveillantes (changement des informations d'identification, transfert d'argent ...), exploitant le fait que le le navigateur enverra tous les cookies de connexion et de session encore en vie et valides pour votre site.
Si CORS est correctement configuré, la demande ajax du site de l'attaquant sera rejetée, car, par défaut, il n'acceptera que les demandes du même site.
Cela ne signifie PAS que vous ne devez pas désinfecter vos entrées, et vous protège uniquement contre un certain type d'attaques CSFR. Si l'attaquant obtient les cookies/jetons d'accès de votre utilisateur, il y aura quand même accès, et c'est pourquoi la plupart des processus d'authentification doivent utiliser SSL comme couche de protection supplémentaire.
PS: Cela suppose que le navigateur que votre utilisateur utilise est à jour, n'a aucun défaut et obéit correctement à la même politique d'origine.
EDIT: comme pour les demandes de contrôle en amont, il s'agit d'une mesure supplémentaire pour s'assurer que le site est autorisé à accéder, et ne sont pas effectuées pour toutes les demandes d'origine croisée
Est-il sensé de résumer tout cela comme suit:
SOP (Single Origin Policy) garantit que les attaques CSRF ne peuvent pas être effectuées à partir de dans un navigateur moderne et à jour dû au fait que l'attaquant devrait publier à partir d'un autre domaine.
CSRF (Cross-Site Request Forgery) les jetons garantissent que les POST requêtes ne peuvent pas être faites en dehors de le navigateur (où SOP ne s'applique pas, par exemple en utilisant
curl), car ils n'ont pas accès aux données d'authentification dans les cookies utilisateur en dehors d'un navigateur partagé expérience.CORS (Cross-Origin Resource Sharing) peut être utilisé pour assouplir les restrictions sur SOP aux navigateurs, mais uniquement si le serveur de ressources le permet via les en-têtes CORS. Par conséquent, il a le potentiel d'affaiblir la sécurité en cas d'utilisation incorrecte.
J'ai lu au cours des derniers jours sur CORS et dans de nombreux endroits, il est mentionné car il s'agit d'une fonctionnalité de "sécurité" pour aider le monde contre la contrefaçon interdomaine.
Soit vous avez mal compris les avantages de CORS, soit vous l'avez lu dans certains amateurs blogs réalisés par des développeurs plus inquiets comment le faire fonctionner que comment le rendre sûr (si vous comprenez ce que je veux dire), car CORS rend plutôt votre application Web vulnérable à de telles attaques ( CSRF ) lorsque vous ouvrez des requêtes d'origine croisée provenant de l'origine de l'attaquant en utilisant CORS avec l'en-tête suivant: Access-Control-Allow-Origin: *
Comment CORS aide-t-il et quels en sont les avantages?
CORS est né pour alléger les restrictions des SOP pour requêtes de confiance seulement. Mais les problèmes commencent exactement avec cela confiance. Un attaquant pourrait faire du mal à travers les origines en forgeant des requêtes malveillantes via GET et POST par exemple, et vous exposer même DNS rebinding
Quant à cette partie,
les navigateurs feront une demande de contrôle en amont/le serveur validera l'origine. Mais un attaquant peut facilement créer un HttpRequest de haut en bas avec les en-têtes (origine) qu'il souhaite et il aura accès à la ressource.
De https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
De plus, pour les méthodes de requête HTTP qui peuvent provoquer des effets secondaires sur les données utilisateur (en particulier, pour les méthodes HTTP autres que GET, ou pour POST avec certains types MIME), la spécification exige que les navigateurs "contrôle en amont" la demande, en sollicitant les méthodes prises en charge auprès du serveur avec une méthode de demande HTTP OPTIONS, puis, sur "approbation" du serveur, en envoyant la demande réelle avec la méthode de demande HTTP réelle. Les serveurs peuvent également informer les clients si des "informations d'identification" (y compris les cookies et les données d'authentification HTTP) doivent être envoyés avec les demandes.
Autant que je sache, si vous utilisez des méthodes HTTP comme 'PUT' au lieu de 'POST' et parce que faire une demande inter-domaines en utilisant 'PUT 'comme la méthode spécifiée sera toujours précédée d'une vérification de la demande avant le vol pour voir si l'origine est autorisée, cela peut empêcher les attaques dans certaines situations. En effet, l'origine ne peut pas être usurpée par l'attaquant car les navigateurs modernes n'autorisent pas les langages de script côté client tels que Javascript vers définissez l''origine 'ou tout en-tête personnalisé inter-domaines, l'attaque échouera .
J'espère que cela a aidé.
Oui, cela aide, mais pas vraiment par conception.
CORS signifie Partage des ressources d'origine croisée . Ce n'est pas vraiment destiné à la sécurité. CORS est replié dans fetch API , il n'est donc utile que pour Javascript (plus à ce sujet plus tard). Par défaut, fetch() ne peut pas récupérer ce qui n'est pas dans la même origine en raison de la stratégie d'origine unique (SOP). CORS relâche cela en disant ce que autre origines sont autorisées à accéder à une ressource. De plus, XMLHttpRequest se comporte de la même manière.
Donc, oui, cela peut aider à bloquer les scripts intersites (XSS) car la ressource essaie d'accéder à partir d'une autre origine. Et techniquement, votre serveur ne bloque pas la demande. C'est un navigateur qui ne laisse pas passer la demande en respectant le Access-Control-Allow-Origin entête.
Mais ce n'est que pour Javascript. Les navigateurs n'utilisent pas CORS pour Demandes simples .
Cela signifie que les requêtes GET simples (comme les fausses images) ne sont pas arrêtées par CORS. De plus, POST les requêtes non effectuées en Javascript (ie: formulaires) ne déclenchent pas CORS. Vous avez toujours besoin d'une protection contre cela. La sécurité est aussi forte que votre maillon le plus faible, et une fois que vous commencez à empêcher CSRF au niveau du serveur de Simple Demandes , vous vous rendrez compte que votre CORS n'est qu'une couche supplémentaire qui n'est pas vraiment nécessaire, mais toujours agréable à avoir.