跨域表单发布

我已经看到关于这个主题的文章和post（包括SO），而且主stream的评论是同源策略阻止跨域的POST表单。 我见过的唯一一个人提出，同源政策不适用于形成职位， 在这里 。

我想有一个更“官方”或正式来源的答案。 例如，有没有人知道解决如何同源或不影响表单POST的RFC？

澄清 ：我不是问一个GET或POST是否可以构build并发送到任何域。 我问：

1. 如果Chrome，IE或Firefox允许来自域“Y”的内容向域“X”发送POST，
2. 如果接收POST的服务器实际上将看到任何表单值。 我这样说是因为大多数在线讨论logging的testing者说服务器收到post，但是表单的值都是空的/剥离的。
3. 什么官方文档（即RFC）解释了什么预期的行为（无论浏览器目前实施）。

顺便说一句，如果同源不影响表单邮政 – 那么它为什么需要防伪令牌更为明显。 我说“有点”，因为看起来太容易相信攻击者可以简单地发出一个HTTP GET来检索包含反伪造标记的表单，然后做一个包含相同标记的非法POST。 注释？

Answer 1

同样的来源策略仅适用于浏览器端编程语言。 所以，如果你尝试使用JavaScript发布到不同于原始服务器的服务器上，那么相同的原始策略会发挥作用，但是如果你从表单直接发布，即操作指向不同的服务器，如：

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

而且在发布表单时没有涉及javascript，那么同样的来源策略是不适用的。

请参阅维基百科获取更多信息

Answer 2

可以构build一个任意的GET或POST请求，并将其发送给受害者浏览器可访问的任何服务器 。 这包括本地networking上的设备，如打印机和路由器。

build立CSRF漏洞有很多方法。 可以使用.submit()方法发送简单的基于POST的CSRF攻击 。 更复杂的攻击，如跨站点file uploadCSRF攻击将利用CORE使用xhr.withCredentals行为 。

CSRF不违反JavaScrip的同源策略，因为SOP关心JavaScript 读取服务器对客户请求的响应。 CSRF攻击并不关心响应，他们关心的是副作用 ，或者请求产生的状态变化，例如添加pipe理用户或者在服务器上执行任意代码。

确保您的请求使用OWASP CSRF预防备忘单中描述的方法之一进行保护。 有关CSRF的更多信息，请参阅CSRF上的OWASP页面 。

Answer 3

相同的来源策略与将请求发送到另一个URL（不同的协议或域或端口）无关。

这是关于限制从另一个URL访问（读取）响应数据。 因此，页面中的JavaScript代码可以发布到任意域，或者在该页面内将表单提交到任何位置（除非表单位于具有不同url的iframe中）。

但是这些POST请求的低效率是因为这些请求缺less防伪令牌，所以被其他url忽略。 而且，如果JavaScript尝试获取安全令牌，则通过向受害者url发送AJAX请求，阻止通过同源策略访问该数据。

一个很好的例子： 在这里

还有一个来自Mozilla的好文档： 这里