Politique de même origine et CORS (partage de ressources entre origines)
J'essayais de comprendre CORS. Selon ma compréhension, il s'agit d'un mécanisme de sécurité implémenté dans les navigateurs pour éviter toute demande ajax vers un domaine autre que celui ouvert par l'utilisateur (spécifié dans l'url )
Maintenant, en raison de cette limitation, de nombreux CORS ont été mis en œuvre pour permettre aux sites Web d'effectuer des demandes d'origine croisées. mais selon ma compréhension, l'implémentation de CORS défie l'objectif de sécurité de la "même politique d'origine" [~ # ~] sop [~ # ~]
CORS est juste pour fournir un contrôle supplémentaire sur le serveur de requêtes qui veut servir. Peut-être que cela peut éviter les spammeurs.
De Wikipedia :
Pour lancer une demande multi-origine, un navigateur envoie la demande avec un en-tête HTTP d'origine. La valeur de cet en-tête est le site qui a servi la page. Par exemple, supposons qu'une page sur http://www.example-social-network.com tente d'accéder aux données d'un utilisateur dans online-personal-calendar.com. Si le navigateur de l'utilisateur implémente CORS, l'en-tête de demande suivant serait envoyé:
Origine: http://www.example-social-network.com
Si online-personal-calendar.com autorise la demande, il envoie un en-tête Access-Control-Allow-Origin dans sa réponse. La valeur de l'en-tête indique quels sites d'origine sont autorisés. Par exemple, une réponse à la demande précédente contiendrait les éléments suivants:
Access-Control-Allow-Origin: http://www.example-social-network.com
Si le serveur n'autorise pas la demande d'origine croisée, le navigateur enverra une erreur à la page example-social-network.com au lieu de la réponse online-personal-calendar.com.
Pour autoriser l'accès à toutes les pages, un serveur peut envoyer l'en-tête de réponse suivant:
Contrôle d'accès-autorisation-origine: *
Cependant, cela pourrait ne pas convenir aux situations dans lesquelles la sécurité est une préoccupation.
Qu'est-ce que j'oublie ici? quel est le but de CORS pour sécuriser le serveur vs sécuriser le client.
Politique de même origine
Qu'est-ce que c'est?
La même politique d'origine est une mesure de sécurité normalisée parmi les navigateurs. Le "Origine" fait principalement référence à un "domaine". Il empêche différentes origines d'interagir les unes avec les autres, pour empêcher des attaques telles que Cross Site Request Forgery.
Comment fonctionne une attaque CSRF?
Les navigateurs permettent aux sites Web de stocker des informations sur l'ordinateur d'un client, sous forme de cookies. Ces cookies ont des informations qui leur sont attachées, comme le nom du cookie, quand il a été créé, quand il expirera, qui a défini le cookie, etc. Un cookie ressemble à ceci:
Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]
Il s'agit donc d'un cookie au chocolat, qui devrait être accessible depuis http://bakery.com et tous ses sous-domaines.
Ce cookie peut contenir des données sensibles. Dans ce cas, ces données sont ... chocolate. Très sensible, comme vous pouvez le voir.
Le navigateur stocke donc ce cookie. Et chaque fois que l'utilisateur fait une demande à un domaine sur lequel ce cookie est accessible, le cookie est envoyé au serveur de ce domaine. Serveur heureux.
C'est une bonne chose. Un moyen super cool pour le serveur de stocker et de récupérer des informations sur et depuis le côté client.
Mais le problème est que cela permet à http://malicious-site.com d'envoyer ces cookies à http://bakery.com , sans l'utilisateur sachant ! Par exemple, considérons le scénario suivant:
# malicious-site.com/attackpage
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();
Si vous visitez le site malveillant et que le code ci-dessus s'exécute et que la politique de même origine n'était pas là, l'utilisateur malveillant passerait une commande au nom de vous et recevrait la commande chez lui ... et cela pourrait ne pas vous plaire .
Cela est arrivé parce que votre navigateur a envoyé votre cookie au chocolat à http://bakery.com , ce qui a fait http://bakery.com penser que vous font la demande pour la nouvelle commande, sciemment. Mais tu ne l'es pas.
Il s'agit, en termes simples, d'une attaque CSRF. Une fausse demande a été faite sur tous les sites. "Contrefaçon de demande intersite". Et cela ne fonctionnerait pas, grâce à la même politique d'origine.
Comment la politique d'origine identique résout-elle cela?
Il empêche le site malveillant-.com de faire des demandes à d'autres domaines. Facile.
En d'autres termes, le navigateur pas permettrait à n'importe quel site de faire une demande à tout autre site. Cela empêcherait différentes origines d'interagir les unes avec les autres via de telles demandes, comme AJAX.
Cependant , le chargement des ressources à partir d'autres hôtes comme les images, les scripts, les feuilles de style, les iframes, les soumissions de formulaires, etc. ne sont pas soumis à cette limitation. Nous avons besoin d'un autre mur pour protéger notre boulangerie des sites malveillants, en utilisant Tokens CSRF .
Jetons CSRF
Comme indiqué, un site malveillant peut toujours faire quelque chose comme ça sans enfreindre la même politique d'origine:
<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>
Et le navigateur essaiera de charger une image à partir de cette URL, ce qui entraînera une demande GET à cette URL en envoyant tous les cookies. Pour empêcher cela, nous avons besoin d'une protection côté serveur.
Fondamentalement, nous attachons un jeton unique et aléatoire d'entropie appropriée à la session de l'utilisateur, le stockons sur le serveur et l'envoyons également au client avec le formulaire. Lorsque le formulaire est soumis, le client envoie ce jeton avec la demande et le serveur vérifie si ce jeton est valide ou non.
Maintenant que nous l'avons fait et qu'un site Web malveillant envoie à nouveau la demande, il échouera toujours car il n'y a aucun moyen possible pour le site Web malveillant de connaître le jeton pour la session de l'utilisateur.
CORS
Si nécessaire, la politique peut être contournée, lorsque des demandes intersites sont requises. Ceci est connu sous le nom de [~ # ~] cors [~ # ~]. Partage de ressources entre origines.
Cela fonctionne en faisant en sorte que les "domaines" indiquent au navigateur de se détendre et autorisent de telles demandes. Cette chose "révélatrice" peut se faire en passant un en-tête. Quelque chose comme:
Access-Control-Allow-Origin: //comma separated allowed origins list, or just * Donc, si http://bakery.com transmet cet en-tête au navigateur et la page créant la demande à http://bakery.com est présent dans la liste d'origine, le navigateur laissera passer la demande, ainsi que les cookies.
Il existe des règles selon lesquelles l'origine est définie1. Par exemple, différents ports pour le même domaine ne sont pas la même origine. Le navigateur peut donc refuser cette demande si les ports sont différents. Comme toujours, notre chère Internet Explorer est l'exception à cela. IE traite tous les ports de la même manière. Il s'agit non standard et aucun autre navigateur se comporte de cette façon. Ne vous fiez pas à cela .
JSONP
JSON avec remplissage est juste un moyen de contourner la politique de même origine, lorsque CORS n'est pas une option. C'est risqué et une mauvaise pratique. Évitez de l'utiliser.
Cette technique implique de faire une demande à l'autre serveur comme suit:
<script src="http://badbakery.com/jsonpurl?callback=cake"></script>
Étant donné que la politique de même origine n'empêche pas cela2 demande, la réponse de cette demande sera chargée dans la page.
Cette URL répondrait très probablement avec du contenu JSON. Mais simplement inclure ce contenu JSON sur la page ne va pas aider. Cela entraînerait bien sûr une erreur. Donc http://badbakery.com accepte un paramètre de rappel et modifie les données JSON, en les envoyant enveloppées dans tout ce qui est passé au paramètre de rappel.
Donc, au lieu de revenir,
{ user: "vuln", acc: "B4D455" }
qui est un code JavaScript invalide, générant une erreur, il retournerait,
cake({user: "vuln", acc:"B4D455"});
qui est du JavaScript valide, il serait exécuté et probablement stocké quelque part selon la fonction cake, de sorte que le reste du JavaScript de la page puisse utiliser les données.
Ceci est principalement utilisé par les API pour envoyer des données à d'autres domaines. Encore une fois, c'est une mauvaise pratique, peut être risquée et doit être strictement évitée.
Pourquoi JSONP est-il mauvais?
Tout d'abord, c'est très limité. Vous ne pouvez pas gérer d'erreurs si la demande échoue (du moins pas de manière saine). Vous ne pouvez pas réessayer la demande, etc.
Cela nécessite également que vous ayez une fonction cake dans la portée global qui n'est pas très bonne. Puisse les cuisiniers vous sauver si vous devez exécuter plusieurs requêtes JSONP avec différents rappels. Ce problème est résolu par des fonctions temporaires de diverses bibliothèques, mais c'est toujours une façon hackée de faire quelque chose de hack.
Enfin, vous insérez du code JavaScript aléatoire dans le DOM. Si vous n'êtes pas sûr à 100% que le service à distance renverra des gâteaux sûrs, vous ne pouvez pas vous fier à cela.
Références
1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-Origin_policy#Definition_of_an_Origin
2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details
Autres lectures dignes
http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html
http://tools.ietf.org/html/rfc3986 (désolé: p)
https://developer.mozilla.org/en-US/docs/Web/Security/Same-Origin_policy
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_ (CSRF)
La même politique d'origine (SOP) est la politique mise en œuvre par les navigateurs pour prévenir les vulnérabilités via Cross Site Scripting (XSS). C'est principalement pour protéger le serveur, car il y a de nombreuses occasions où un serveur peut gérer l'authentification, les cookies, les sessions, etc.
Le partage des ressources d'origine croisée (CORS) est l'une des rares techniques pour détendre le SOP. Parce que SOP est "on" par défaut, la définition de CORS côté serveur permettra d'envoyer une demande au serveur via une XMLHttpRequest même si la demande a été envoyée à partir d'un domaine différent. devient utile si votre serveur était destiné à répondre aux demandes d'autres domaines (par exemple, si vous fournissez une API).
J'espère que cela clarifie la distinction entre SOP et CORS et les objectifs de chacun.