Html 跨域表单发布
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/11423682/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Cross Domain Form POSTing
提问by Brent Arias
I've seen articles and posts all over (including SO) on this topic, and the prevailing commentary is that same-origin policy prevents a form POST across domains. The only place I've seen someone suggest that same-origin policy does not apply to form posts, is here.
我已经看到关于这个主题的文章和帖子（包括 SO），流行的评论是同源策略阻止跨域的表单 POST。我看到有人建议同源政策不适用于表单帖子的唯一地方是这里。
I'd like to have an answer from a more "official" or formal source. For example, does anyone know the RFC that addresses how same-origin does or does not affect a form POST?
我想从更“官方”或更正式的来源获得答案。例如，是否有人知道解决同源性如何或不影响表单 POST 的 RFC？
clarification: I am not asking if a GET or POST can be constructed and sent to any domain. I am asking:
澄清：我不是在问是否可以构造 GET 或 POST 并将其发送到任何域。我在问：
- if Chrome, IE, or Firefox will allow content from domain 'Y' to send a POST to domain 'X'
- if the server receiving the POST will actually see any form values at all. I say this because the majority of online discussion records testers saying the server received the post, but the form values were all empty / stripped out.
- What official document (i.e. RFC) explains what the expected behavior is (regardless of what the browsers have currently implemented).
- 如果 Chrome、IE 或 Firefox 允许域“Y”中的内容向域“X”发送 POST
- 如果接收 POST 的服务器实际上会看到任何表单值。我这样说是因为大多数在线讨论记录测试人员说服务器收到了帖子，但表单值都是空的/被剥离了。
- 什么官方文件（即 RFC）解释了预期的行为是什么（无论浏览器当前实现了什么）。
Incidentally, if same-origin does not affect form POSTs - then it makes it somewhat more obvious of why anti-forgery tokens are necessary. I say "somewhat" because it seems too easy to believe that an attacker could simply issue an HTTP GET to retrieve a form containing the anti-forgery token, and then make an illicit POST which contains that same token. Comments?
顺便说一句，如果同源不影响表单 POST - 那么它就更明显地说明为什么需要防伪令牌。我说“有点”是因为似乎很容易相信攻击者可以简单地发出 HTTP GET 来检索包含防伪令牌的表单，然后进行包含相同令牌的非法 POST。注释？
回答by Suresh Kumar
The same origin policy is applicable only for browser side programming languages. So if you try to post to a different server than the origin server using JavaScript, then the same origin policy comes into play but if you post directly from the form i.e. the action points to a different server like:
同源策略仅适用于浏览器端编程语言。因此，如果您尝试使用 JavaScript 发布到与源服务器不同的服务器，那么相同的源策略就会发挥作用，但如果您直接从表单发布，即操作指向不同的服务器，例如：
<form action="http://someotherserver.com">
and there is no javascript involved in posting the form, then the same origin policy is not applicable.
并且在发布表单时不涉及 javascript，则同源策略不适用。
See wikipediafor more information
有关更多信息，请参阅维基百科
回答by Mikey
It is possible to build an arbitrary GET or POST request and send it to any serveraccessible to a victims browser. This includes devices on your local network, such as Printers and Routers.
可以构建任意的 GET 或 POST 请求并将其发送到受害者浏览器可访问的任何服务器。这包括本地网络上的设备，例如打印机和路由器。
There are many ways of building a CSRF exploit. A simple POST based CSRF attackcan be sent using .submit()method. More complex attacks, such as cross-site file upload CSRF attackswill exploit CORS use of the xhr.withCredentals behavior.
有很多方法可以构建 CSRF 漏洞利用。 可以使用方法发送一个简单的基于 POST 的 CSRF 攻击.submit()。更复杂的攻击，例如跨站点文件上传 CSRF 攻击将利用CORS 使用 xhr.withCredentials 行为。
CSRF does not violate the Same-Origin Policy For JavaScript because the SOP is concerned with JavaScript readingthe server's response to a clients request. CSRF attacks don't care about the response, they care about a side-effect, or state change produced by the request, such as adding an administrative user or executing arbitrary code on the server.
CSRF 不违反JavaScript 的同源策略，因为 SOP 关注 JavaScript读取服务器对客户端请求的响应。CSRF 攻击不关心响应，他们关心副作用或请求产生的状态变化，例如添加管理用户或在服务器上执行任意代码。
Make sure your requests are protected using one of the methods described in the OWASP CSRF Prevention Cheat Sheet. For more information about CSRF consult the OWASP page on CSRF.
使用OWASP CSRF Prevention Cheat Sheet 中描述的方法之一确保您的请求受到保护。有关 CSRF 的更多信息，请参阅 CSRF 上的OWASP 页面。
回答by Mohsenme
Same origin policy has nothing to do with sending request to another url (different protocol or domain or port).
同源策略与将请求发送到另一个 url（不同的协议或域或端口）无关。
It is all about restricting access to (reading) response data from another url. So JavaScript code within a page can post to arbitrary domain or submit forms within that page to anywhere (unless the form is in an iframe with different url).
这完全是关于限制从另一个 url 访问（读取）响应数据。因此，页面中的 JavaScript 代码可以发布到任意域或将该页面中的表单提交到任何地方（除非表单位于具有不同 url 的 iframe 中）。
But what makes these POST requests inefficient is that these requests lack antiforgery tokens, so are ignored by the other url. Moreover, if the JavaScript tries to get that security tokens, by sending AJAX request to the victim url, it is prevented to access that data by Same Origin Policy.
但是使这些 POST 请求效率低下的原因是这些请求缺少防伪令牌，因此被其他 url 忽略。此外，如果 JavaScript 试图通过向受害者 url 发送 AJAX 请求来获取该安全令牌，则同源策略会阻止访问该数据。
A good example: here
一个很好的例子：这里
And a good documentation from Mozilla: here
还有来自 Mozilla 的一个很好的文档：here
