Comment le CSRF est-il en corrélation avec la politique de même origine
J'essaie de comprendre quels rôles jouent CSRF et même origine dans le grand schéma des choses. Avec CSRF, je suis capable de faire à peu près n'importe quoi sur d'autres sites Web sur des clients en faisant des demandes.La même politique d'origine (SOP) préserve les données d'autres domaines et annule donc l'utilisation de CSRF.
Maintenant, considérant que la même politique d'origine s'applique uniquement à XMLHTTPRequest, donc avec un formulaire intelligemment conçu, je peux faire une POST qui annule la SOP et donc la nécessité pour les jetons CSRF.
Maintenant, avec tout cela, le CSRF fonctionne-t-il autour du SOP ou fonctionne à travers? Je trouve difficile de répondre, mais c'est peut-être parce que la question elle-même prête à confusion.
Commençons par définir le terme "origine". L'origine d'une page est déterminée par trois facteurs uniques: nom d'hôte, protocole et numéro de port. Par exemple, http://test.com et https://test.com ont des origines différentes car le protocole est différent. De même http://one.test.com et http://two.test.com ont des origines différentes car les noms d'hôtes sont différents. La propriété Origin est également différente pour deux services exécutés sur le même hôte avec des numéros de port différents, par exemple http://test.com:8081 et http://test.com:8082 sont considérés comme des origines différentes.
La même politique d'origine (SOP) est un contrôle de sécurité au niveau du navigateur qui dicte comment un document ou un script servi par une origine peut interagir avec une ressource d'une autre origine. Fondamentalement, cela empêche les scripts exécutés sous une origine de lire les données d'une autre origine .
Les demandes inter-domaines et les soumissions de formulaires sont toujours autorisées mais la lecture des données d'une autre origine n'est pas autorisée. Cela signifie que si vous effectuez une attaque CSRF sur un site vulnérable qui entraîne un changement d'état côté serveur (par exemple, création d'utilisateur, suppression de document, etc.), l'attaque réussira mais vous ne pourrez pas lire la réponse.
En bref SOP empêche uniquement la lecture des données qui ont été servies à partir d'une origine différente. Il ne couvre pas les soumissions de formulaires interdomaines qui sont utilisées pour effectuer une attaque CSRF.
En ce qui concerne la communication entre domaines à l'aide de AJAX est concerné, il existe quelques autres contrôles de sécurité qui dictent la communication. Reportez-vous à Cross Origin Resource Sharing . CORS permet différentes origines pour communiquer et partager des données de manière contrôlée et une mauvaise configuration de CORS peut également entraîner vulnérabilités de sécurité .
Notez que SOP n'empêche pas les ressources hébergées sur différents domaines d'être incorporées dans une page en utilisant des balises de script, CSS et des balises d'image. Bien que cela puisse ne pas permettre une lecture directe du contenu, les effets secondaires du chargement et du rendu peuvent être utilisés pour déterminer (des parties du) contenu. Notez également que les Websockets ne sont pas du tout couverts par SOP et donc la lecture intersite est possible.
P.S. Tiré de mon blog .
La même politique d'origine (SOP) préserve les données des autres domaines ...
Le SOP comprend deux parties:
- Il empêche les scripts sur l'origine A de lire les données de l'origine B.
- Il empêche les sites de l'origine A d'envoyer quoi que ce soit, mais des demandes dites "simples" à l'origine B. Les demandes simples sont limitées à GET et POST, et seuls quelques en-têtes peuvent être modifiés.
... et annule donc l'utilisation de CSRF.
Le SOP ne protège pas contre CSRF. Pourquoi?
- Une attaque CSRF se fait en envoyant une demande, et non en lisant quoi que ce soit dans la réponse. En fait, vous ne pouvez ni ne devez lire la réponse.
- Vous utiliseriez normalement de simples requêtes dans une attaque CSRF.
Comme vous pouvez le voir, les limitations mentionnées ci-dessus que le SOP met en place n'empêche pas les attaques CSRF.
Considérant maintenant que la même politique d'origine s'applique uniquement à XMLHTTPRequest ...
Non. Il s'applique à toutes les données qu'un navigateur gère. Si vous utilisez XMLHTTPRequest, un formulaire ordinaire ou l'API fetch n'est pas pertinent. Les mêmes restrictions s'appliquent.
... donc avec une forme intelligemment conçue, je peux faire une POST qui annule le SOP et donc la nécessité de jetons CSRF.
Avec un formulaire spécialement conçu, vous pouvez faire une demande POST qui exécute une attaque CSRF, oui. Et c'est pourquoi vous avez besoin d'une protection spéciale, comme des jetons CSRF.
Maintenant, avec tout cela, le type CSRF fonctionne-t-il autour du SOP ou fonctionne-t-il?
Je ne sais pas ce que "contourner" ou "parcourir" le SOP voudrait dire. Au lieu de cela, permettez-moi de dire ceci: CSRF est possible parce que les navigateurs vous permettent d'envoyer des croix d'origine POST requêtes.
Un site A peut provoquer une requête vers les différents sites B de différentes manières, par exemple en incluant une image du site B dans le code HTML du site A (c'est-à-dire <img src=http://B/...>) ou faites des choses similaires avec des formulaires ou des redirections Javascript ou HTTP. Les demandes lancées à partir d'un site mais dirigées vers un autre site sont appelées demandes intersites.
La falsification de demande intersite (CSRF) signifie qu'une demande intersite peut être utilisée à mauvais escient. C'est généralement le cas car un cookie de session existant d'une connexion précédente au site B est envoyé à chaque demande sur ce site, même si la demande est initiée à partir du site A, c'est-à-dire intersite. Cela signifie que la demande est exécutée avec l'identité de l'utilisateur connecté sur le côté B. Une attaque CSRF réussie signifie qu'une telle demande intersite peut causer des dommages, par exemple en en changeant les paramètres DNS dans un routeur vulnérable à CSRF .
La politique de même origine (SOP) ne rend pas CSRF impossible, mais elle limite en quelque sorte l'impact de CSRF dans la mesure où la demande est envoyée au site B mais le résultat renvoyé par le serveur du site B ne peut pas être vu par l'attaquant. Ainsi SOP rend CSRF en écriture seule, c'est-à-dire que CSRF peut être utilisé pour exécuter des actions indésirables, mais il ne peut pas être utilisé seul pour exfiltrer des données du site B. Par exemple, un attaquant externe pourrait utiliser une vulnérabilité CSRF dans un Wiki d'entreprise interne pour créer une nouvelle publication au nom d'un utilisateur existant ou supprimer une publication, mais en raison de SOP il ne peut pas lire le contenu du Wiki interne et le renvoyer au attaquant externe.
Notez que toutes les communications intersites ne sont pas limitées par le SOP. Notamment les Websockets ne sont pas limités et il est donc possible pour un attaquant du site A d'utiliser un navigateur comme trampoline pour communiquer pleinement avec un Websocket du site B avec les autorisations de l'utilisateur connecté, c'est-à-dire à la fois écrire et lire des données.