跨域资源共享的安全性答案

【问题标题】：Security for cross-origin resource sharing跨域资源共享的安全性
【发布时间】：2012-10-25 21:00:58
【问题描述】：

我有 2 个 ruby on rails 应用程序位于 2 个不同的域（例如 www.exampleA.com 和 www.exampleB.com。我想在这两个应用程序之间共享资源，我正在使用 CORS：

exampleA.com 向 exampleB.com 发送 http POST 请求。

在exampleB.com，我正在检查request.env['HTTP_ORIGIN'] 以确保请求来自exampleA.com。如果为真，我会通过设置响应标头来允许 http post 请求来响应。

我的问题是我可以使用request.env['HTTP_ORIGIN'] 作为唯一检查来验证请求者的身份吗？

来自 www.exampleC.com 的人是否有可能伪造他们的 HTTP_ORIGIN 看起来像 www.exampleA.com 并发布恶意数据？如果是这样，验证请求者身份的最佳方法是什么？

【问题讨论】：

【解决方案1】：

Origin 是几个header fields that cannot be set for a XHR request by page authors 之一。因此，您可以放心地信任 XHR 请求的 Origin 信息。

但攻击者仍有可能直接发送带有恶意数据的伪造请求。所以你仍然需要验证传入的请求。

【讨论】：

“安全”是相对的。考虑是否有人能够发送他们喜欢的任何数据（例如来自恶意本机应用程序、Flash 或 Java 中的漏洞等），以及这是否会使您或他们面临安全风险代表您执行操作

【解决方案2】：

抱歉，伪造大多数客户端提供的数据（包括来源）非常容易，因此不应将其用于任何类型的安全性。

【讨论】：

但是无论如何这都是客户端，并且 OP 正在启用客户端机制 (CORS)，因此如果客户端伪造了引用者，他们只会减少 他们自己的保护。
@SilverlightFox - 来自 op “来自 www.exampleC.com 的人是否有可能伪造他们的 HTTP_ORIGIN 看起来像 www.exampleA.com 并发布恶意数据？”
是的，他们可以直接发出请求，但不能在客户端也包含受害者的身份验证 cookie。
我没有做任何假设。
那么它在 OP 中的什么地方说“auth cookie”？我已经和你讨论完了这件事。如果您需要进一步澄清，请将其作为问题提出，以便比我现在更关心的人处理...