136 votes

Cross Domain Form POSTing

J'ai vu des articles et des messages un peu partout (y compris sur SO) sur ce sujet, et le commentaire dominant est que la politique de same-origin empêche un formulaire POST à travers les domaines. Le seul endroit où j'ai vu quelqu'un suggérer que la politique de l'origine commune ne s'applique pas aux formulaires POST, est ici .

J'aimerais avoir une réponse d'une source plus "officielle" ou formelle. Par exemple, quelqu'un connaît-il la RFC qui traite de la façon dont le same-origin affecte ou non 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 :

  1. si Chrome, IE ou Firefox autorise le contenu du domaine "Y" à envoyer un POST au domaine "X".
  2. si le serveur qui reçoit le POST verra réellement les valeurs du formulaire. Je dis cela parce que la majorité des discussions en ligne font état de testeurs disant que le serveur a reçu le message, mais que les valeurs du formulaire étaient toutes vides / supprimées.
  3. Quel document officiel (i.e. RFC) explique quel est le comportement attendu (indépendamment de ce que les navigateurs ont actuellement mis en œuvre).

Par ailleurs, si le principe du same-origin n'affecte pas les formulaires POST, la raison pour laquelle les jetons anti-falsification sont nécessaires devient un peu plus évidente. Je dis "un peu" parce qu'il semble trop facile de croire qu'un attaquant pourrait simplement lancer un HTTP GET pour récupérer un formulaire contenant le jeton anti-falsification, puis effectuer un POST illicite contenant ce même jeton. Des commentaires ?

162voto

Suresh Kumar Points 3170

La même politique d'origine s'applique uniquement aux langages de programmation côté navigateur. Ainsi, si vous essayez d'envoyer un message à un serveur différent du serveur d'origine en utilisant JavaScript, la même politique d'origine entre en jeu, mais si vous envoyez un message directement à partir du formulaire, c'est-à-dire que l'action pointe vers un serveur différent, par exemple :

<form action="http://someotherserver.com">

et qu'il n'y a pas de javascript impliqué dans l'affichage du formulaire, alors la même politique d'origine n'est pas applicable.

Ver wikipedia pour plus d'informations

41voto

Mikey Points 344

Il est possible de construire une requête GET ou POST arbitraire et de l'envoyer à tout serveur accessible à un navigateur de victimes. 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 construire un exploit CSRF. Une attaque CSRF simple basée sur le POST peut être envoyé en utilisant .submit() méthode. Des attaques plus complexes, telles que attaques CSRF par téléchargement de fichiers intersites exploitera Utilisation CORS du comportement xhr.withCredentals .

CSRF ne viole pas la Politique de même origine pour JavaScrip pas parce que le SOP est concerné par le JavaScript lecture la réponse du serveur à la demande du client. Les attaques CSRF ne se soucient pas de la réponse, elles se soucient d'une effet secondaire ou un changement d'état produit par la demande, comme l'ajout d'un utilisateur administratif ou l'exécution d'un code arbitraire sur le serveur.

Assurez-vous que vos demandes sont protégées en utilisant l'une des méthodes décrites dans le document Fiche de prévention CSRF de l'OWASP . Pour plus d'informations sur CSRF, consultez le Page de l'OWASP sur CSRF .

18voto

Mohsenme Points 195

La politique de la même origine n'a rien à voir avec l'envoi d'une demande à une autre url (protocole, domaine ou port différents).

Il s'agit de restreindre l'accès (la lecture) aux données de réponse d'une autre url. Ainsi, le code JavaScript d'une page peut envoyer des messages à un domaine arbitraire ou soumettre des formulaires de cette page à n'importe quel endroit (sauf si le formulaire est dans un iframe avec une url différente).

Mais ce qui rend ces requêtes POST inefficaces, c'est qu'elles ne contiennent pas de jetons anti-falsification et sont donc ignorées par l'autre url. De plus, si le JavaScript essaie 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 politique de la même origine.

Un bon exemple : ici

Et une bonne documentation de Mozilla : ici

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X