跨域表单POST

Bre*_*ias 135 html security http csrf same-origin-policy

我已经看过关于这个主题的文章和帖子(包括SO),而流行的评论是同源策略阻止跨域的表单POST.我见过的唯一一个人建议同源政策不适用于表格帖子,就在这里.

我想从更"官方"或正式的消息来源得到答案.例如,有没有人知道解决同源来源如何影响表格POST的RFC?

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

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

顺便提一下,如果同源不影响表单POST,那么它就会更清楚地说明为什么需要使用防伪令牌.我说"有些"因为似乎很容易相信攻击者可以简单地发出HTTP GET来检索包含防伪令牌的表单,然后进行包含相同令牌的非法POST.评论?

Sur*_*mar 162

相同的源策略仅适用于浏览器端编程语言.因此,如果您尝试使用JavaScript发布到与源服务器不同的服务器,则相同的源策略将起作用,但如果您直接从表单发布,即操作指向不同的服务器,如:

<form action="http://someotherserver.com">
Run Code Online (Sandbox Code Playgroud)

并且在发布表单时没有涉及javascript,则相同的原始策略不适用.

有关更多信息,请参阅维基百科

  • 简而言之:是的,允许跨域POST. (19认同)
  • 很抱歉拖到一个旧问题,如果使用JS更改操作但是然后使用按钮发布表单会发生什么?这是否允许成功的跨域帖子? (16认同)
  • -1 for:相同的源策略与向另一个URL(不同的协议或域或端口)发送请求无关,它是关于限制从另一个URL访问(读取)响应数据(从而阻止javascript更新文档)具有来自其他网址的安全令牌的表单. (14认同)
  • 对于 2021 年来到这里的人来说,值得注意的是,Chrome 现在将阻止表单帖子上的一些 cookie,除非它们设置了 SameSite=None 和 Secure=true https://blog.chromium.org/2020/02/samesite- cookie-changes-in-february.html (3认同)
  • 我有同样的想法.我实际上担心安全性,一些第三方JS /病毒改变行动以将表格发布到恶意的某个地方,但意识到这可以在任何接收形式的跨域支付,结果将是相同的.这里的教训真的:检查任何第三方JS文件;) (2认同)

Mik*_*key 41

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

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

CSRF不违反JavaScrip的同源策略,因为SOP关注的是JavaScript 读取服务器对客户端请求的响应.CSRF攻击不关心响应,它们关心请求产生的副作用或状态更改,例如添加管理用户或在服务器上执行任意代码.

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


Moh*_*nme 14

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

这一切都是为了限制从另一个URL访问(读取)响应数据.因此,页面中的JavaScript代码可以发布到任意域或将该页面中的表单提交到任何位置(除非表单位于具有不同URL的iframe中).

但是这些POST请求效率低下的原因是这些请求缺少防伪令牌,因此被其他URL忽略.此外,如果JavaScript尝试获取该安全性令牌,则通过向受害者URL发送AJAX请求,将阻止它通过Same Origin Policy访问该数据.

一个很好的例子:这里

还有来自Mozilla的好文档:这里