J'ai vu des articles et des messages partout (y compris SO) sur ce sujet, et le commentaire dominant est que la politique de même origine empêche un formulaire POST entre les domaines. Le seul endroit où j'ai vu quelqu'un suggérer que la politique de même origine ne s'applique pas aux messages de formulaire, c'est ici .
J'aimerais avoir une réponse d'une source plus "officielle" ou formelle. Par exemple, est-ce que quelqu'un connaît la RFC qui traite de la façon dont la même origine affecte ou n'affecte pas un formulaire POST?
clarification : je ne demande pas si un GET ou un POST peut être construit et envoyé à n'importe quel domaine. Je demande:
- si Chrome, IE ou Firefox autorise le contenu du domaine «Y» à envoyer un POST au domaine «X»
- si le serveur recevant le POST verra en fait des valeurs de formulaire. Je dis cela parce que la majorité des testeurs d'enregistrements de discussion en ligne disent que le serveur a reçu le message, mais que les valeurs du formulaire étaient toutes vides / supprimées.
- Quel document officiel (ie RFC) explique quel est le comportement attendu (indépendamment de ce que les navigateurs ont actuellement implémenté).
Incidemment, si la même origine n'affecte pas les POST de formulaire, cela rend un peu plus évident la raison pour laquelle les jetons anti-contrefaçon sont nécessaires. Je dis "un peu" car il semble trop facile de croire qu'un attaquant pourrait simplement émettre un HTTP GET pour récupérer un formulaire contenant le jeton anti-falsification, puis créer un POST illicite contenant ce même jeton. Commentaires?
Réponses:
La même politique d'origine est applicable uniquement pour les langages de programmation côté navigateur. Donc, si vous essayez de publier sur un serveur différent du serveur d'origine en utilisant JavaScript, la même politique d'origine entre en jeu, mais si vous publiez directement à partir du formulaire, l'action pointe vers un serveur différent comme:
et il n'y a pas de javascript impliqué dans la publication du formulaire, alors la même politique d'origine n'est pas applicable.
Voir wikipedia pour plus d'informations
la source
Il est possible de créer une requête GET ou POST arbitraire et de l'envoyer à n'importe quel serveur accessible à un navigateur victime. Cela inclut les périphériques de votre réseau local, tels que les imprimantes et les routeurs.
Il existe de nombreuses façons de créer un exploit CSRF. Une attaque CSRF simple basée sur POST peut être envoyée à l'aide de
.submit()method. Les attaques plus complexes, telles que les attaques CSRF de téléchargement de fichiers intersites , exploiteront l' utilisation par CORS du comportement xhr.withCredentals .CSRF ne viole pas la politique de même origine pour JavaScrip t car le SOP concerne la lecture par JavaScript de la réponse du serveur à une demande de clients. Les attaques CSRF ne se soucient pas de la réponse, elles se soucient d'un effet secondaire ou d'un changement d'état produit par la requête, comme l'ajout d'un utilisateur administratif ou l'exécution de code arbitraire sur le serveur.
Assurez-vous que vos demandes sont protégées à l'aide de l'une des méthodes décrites dans la feuille de triche de prévention OWASP CSRF . Pour plus d'informations sur CSRF, consultez la page OWASP sur CSRF .
la source
La même politique d'origine n'a rien à voir avec l'envoi de la demande à une autre URL (protocole ou domaine ou port différent).
Il s'agit de restreindre l'accès (lecture) des données de réponse à partir d'une autre URL. Ainsi, le code JavaScript d'une page peut publier sur un domaine arbitraire ou soumettre des formulaires dans cette page n'importe où (à moins que le formulaire ne soit dans un iframe avec une URL différente).
Mais ce qui rend ces requêtes POST inefficaces, c'est que ces requêtes manquent de jetons anti-contrefaçon et sont donc ignorées par l'autre URL. De plus, si le JavaScript tente d'obtenir ces jetons de sécurité, en envoyant une requête AJAX à l'URL de la victime, il est empêché d'accéder à ces données par la même politique d'origine.
Un bon exemple: ici
Et une bonne documentation de Mozilla: ici
la source