POST de formulaires inter-domaines

145

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?

— Brent Arias
source

Oui, un attaquant pourrait faire cela ... avec un navigateur Web ordinaire.

— Michael Hampton

Peut-être qu'il n'y a pas de RFC pour la même raison qu'il n'y a pas de RFC qui disent: "ne publiez pas votre mot de passe sur votre site Web". Les normes Web ne sont requises que lorsque plusieurs parties doivent travailler ensemble pour réaliser quelque chose: la même politique d'origine est davantage un ensemble complexe de «meilleures pratiques de sécurité» qui empêchent les utilisateurs d'être piratés.

— Ciro Santilli 郝海东冠状病六四事件法轮功

@Ciro Veuillez le dire explicitement. Les règles de publication croisée vers d'autres sites n'affectent pas plusieurs parties. Pas besoin du langage brumeux.

— Little Alien

Réponses:

175

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:

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

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

— Suresh Kumar
source

Désolé de faire glisser une ancienne question, que se passerait-il si l'action était modifiée à l'aide de JS mais que le formulaire était ensuite publié à l'aide d'un bouton? Cela permettrait-il une publication inter-domaines réussie?

— Chris

AFAIK ça ne devrait pas être un problème mais je ne l'ai pas essayé moi-même. Ce serait intéressant à découvrir.

— Suresh Kumar

Je suis du même avis. En fait, j'avais des inquiétudes au sujet de la sécurité, certains JS / virus tiers modifiant l'action pour publier le formulaire dans un endroit malveillant, mais j'ai réalisé que cela pouvait être fait sur n'importe quel formulaire de réception de paiement interdomaine ou non et le résultat serait le même. Leçon ici vraiment: vérifiez tous les fichiers JS tiers;)

— Chris

En bref: OUI, le POST entre domaines est autorisé.

— Christian Davén

-1 pour: la même politique d'origine n'a rien à voir avec l'envoi de la requête à 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 (et d'empêcher ainsi javascript de mettre à jour le document avec formulaires qui ont des jetons de sécurité provenant d'autres URL).

— Mohsenme

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 .

— Mikey
source

J'ai mis à jour ma question pour clarifier. De plus, le lien WordPress que vous avez donné implique des exploits qui ont été lancés à partir de la même origine X, plutôt que lancés à partir de plusieurs domaines Y ... donc ce n'est pas le bon scénario d'après ce que je vois.

— Brent Arias du

@Brent Arias oui, ce que vous décrivez en 1 et 2 est exactement égal à ce qu'une attaque CSRF effectue, peut-être devriez-vous essayer d'exécuter l'un des exploits CSRF fournis et de renifler le trafic. J'ai mis à jour mon message, vous devriez lire chaque lien fourni car il répondra à ces questions avec précision. Le point d'une attaque de «falsification de requête intersite» (CSRF) est que la requête provient d'un autre domaine, tous les exploits fournis répondent pleinement à cette exigence fondamentale.

— Mikey du

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

— Mohsenme
source