跨域表格张贴

我看过很多关于这个主题的文章和帖子(包括 SO) ，主流的评论是同源策略阻止跨域的 POST 表单。我见过的唯一一个地方有人建议同源政策不适用于表格职位，在这里。

我希望得到一个更“正式”或更正式的来源的答复。例如，是否有人知道解决同源如何影响 POST 表单的 RFC？

澄清 : 我不是在询问是否可以构造一个 GET 或 POST 并将其发送到任何域。我在问:

  1. 如果 Chrome、 IE 或 Firefox 允许域名“ Y”的内容向域名“ X”发送 POST 消息
  2. 如果接收 POST 的服务器实际上将看到任何表单值。我这样说是因为大多数在线讨论记录测试人员说服务器收到了帖子，但是表单值都是空的/去掉了。
  3. 什么样的官方文档(即 RFC)解释了预期的行为(不管浏览器当前实现了什么)。

顺便说一句，如果同源不影响表单 POST，那么就更明显地说明了为什么需要防伪标记。我之所以说“有点”，是因为似乎很容易相信攻击者可以简单地发出一个 HTTP GET 来检索包含防伪标记的表单，然后制作一个包含相同标记的非法 POST。有意见吗？

126843 次浏览
小开

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

构建 CSRF 漏洞有很多种方法。可以使用 .submit()方法发送 一种简单的基于 POST 的 CSRF 攻击。更复杂的攻击，如 跨站点文件上传 CSRF 攻击将利用 CORS 使用 xhr.withCredentals 行为。

CSRF 没有违反 JavaScript 的同源策略t，因为 SOP 与服务器对客户端请求的响应 JavaScript阅读有关。CSRF 攻击不关心响应，它们关心的是 副作用或请求产生的状态更改，比如添加管理用户或在服务器上执行任意代码。

确保使用 防止 CSRF 作弊表中描述的方法之一保护您的请求。有关 CSRF 的更多信息，请参考 关于 CSRF 的 OWASP 页面。

小开
最佳答案

同源策略只适用于浏览器端编程语言。因此，如果你试图使用 JavaScript 发布信息到不同的服务器，那么同样的原始策略就会发挥作用，但是如果你直接从表单发布信息，比如，操作指向不同的服务器，比如:

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

如果在发布表单时没有涉及到 javascript，那么同样的原始策略就不适用。

有关更多信息，请参见 维基百科

小开

同源策略与向另一个 URL (不同的协议、域或端口)发送请求无关。

这完全是关于限制访问(读取)来自另一个 URL 的响应数据。 因此，页面中的 JavaScript 代码可以发布到任意域，或者将页面中的表单提交到任何地方(除非表单位于具有不同 URL 的 iframe 中)。

但是，使这些 POST 请求效率低下的原因是，这些请求缺乏防伪标记，因此被其他 URL 忽略。此外，如果 JavaScript 试图获取安全令牌，通过向受害者 URL 发送 AJAX 请求，它将被同源策略阻止访问该数据。

一个很好的例子: 给你

以及来自 Mozilla 的一个很好的文档: 给你


提交答案