【问题标题】:Domain-based "authentication" of a CORS requestCORS 请求的基于域的“身份验证”
【发布时间】:2013-12-30 20:52:45
【问题描述】:

我不认为我希望做的事情是可能的。我将描述这个想法。

用户请求foo.com 并获得一个带有脚本的html 页面。该脚本向 bar.com 发出 CORS 请求。 bar.com 的服务器将对/ 的访问限制为真正来自 foo.com 提供的脚本的请求。有没有一种方法可以让服务器安全地推断出请求确实来自 foo.com 上的脚本?

RefererOrigin 标头包含我想使用的信息。但是,显然这些很容易伪造。

bar.com 可以使用请求的可信方面来根据请求的来源更改其行为吗?

假设我可以控制 foo.com 上的脚本和 bar.com 上的服务器。有什么方法可以在脚本中插入无法被模仿脚本的攻击者重放/伪造的东西?假设 foo.com 是公开的,攻击者可以访问脚本。

任何想法或讨论将不胜感激。

【问题讨论】:

  • 如何轻易伪造 Origin 或 Referer 标头,至少在浏览器中如此?这可能曾经是真的,但我相信现在不是真的(至少对于由浏览器控制的 Origin 而言)。
  • @monsur 我想防止攻击者使用任何工具伪造请求。

标签: security http cors


【解决方案1】:

Origin 检查的目的是防止第三方 攻击者强迫目标用户的浏览器做一些危险的事情。 (而Referer 的做法同样糟糕得多,以至于它不太可能具有任何价值。)

但是你不能阻止用户自己通过玩他们的浏览器来发送任何类型的请求。即使您以某种方式使他们无法发送不准确的Origin 标头,他们仍然可能会干扰来自foo.com 的页面内脚本的整个操作(例如使用F12 调试器)以使其执行您没有执行的操作'不打算同时在Origin 中发送foo.com

你不能依赖你发送给用户的脚本在没有更改的情况下被执行,你不能依赖你发送给用户的脚本中的信息是保密的,你甚至不能确定请求来自真正的浏览器。

用户完全控制客户端环境,因此您需要在设计信任模型时牢记这一点。含义取决于您要执行的操作,但可能的通用授权方案是创建一个令牌,表示允许用户在bar.com 上执行哪些操作,并使用foo.com 上的密钥对其进行签名,然后在执行 CORS 请求时将签名的令牌提供给用户以传递给bar.com

【讨论】:

    猜你喜欢
    • 2015-07-02
    • 1970-01-01
    • 1970-01-01
    • 2016-12-16
    • 2016-02-21
    • 2016-10-12
    • 2016-09-29
    • 2017-07-23
    相关资源
    最近更新 更多