我应该在 OAuth 2 回调中验证 HTTP 引用者吗？答案

【问题标题】：Should I verify HTTP Referer in OAuth 2 Callback?我应该在 OAuth 2 回调中验证 HTTP 引用者吗？
【发布时间】：2012-04-13 12:44:31
【问题描述】：

我能够使用我的 Oauth2 servlet 成功地验证 Facebook 和 Google 帐户。我正在使用带有计时器和会话 cookie 的状态来尝试验证它确实是合法的 Oauth 回调。

如果我还检查 HTTP Referer 标头以确保我是从提供商的 OAuth 页面重定向的，会有什么好处吗？
如果没有好处，如果我也检查 HTTP 引用字段会不会有问题？

【问题讨论】：

HTTP Referer 这样的标题可以很容易地模拟。用户可以发送任何标题。
但是我认为您可以检查 ip 地址以确保请求的来源
IP地址不会是用户的吗？
不，来自服务器的令牌将是服务器 IP 地址（facebook、twitter 等）。但是您需要始终控制该 IP 地址列表，它们可能会改变

标签： http authentication oauth http-headers oauth-2.0

【解决方案1】：

不验证 HTTP 引用者； “state”参数（听起来你正在使用）是approach OAuth 2.0 defines，用于防御跨站点请求伪造（CSRF）攻击。

您可能想看看 Ryan Boyd 的新 O'Reilly 书籍Getting Started with OAuth 2.0。它描述了这一点和相关的安全注意事项。

【讨论】：

是的，我正在使用 state 进行非常稳健的检查。感谢 RFC 的链接（但我的工程师有点冒犯了被提到 O'Reilly 的书，因为它只是使用 Oauth 进行身份验证这样简单）
道歉；我不是故意冒犯的！老实说，我发现这本书真的很有价值，这也是我推荐它的主要原因。 =）（那是新的，所以并不广为人知。）我与它没有任何关系；只是一本好书。
哦，请不要道歉！我只是幽默；）我很高兴你发现这本书很有价值，我相信许多其他人也会从详细阅读这本优秀的书中受益！我确信它包含有关复杂客户端、服务器 + 浏览器通信工作流程的宝贵和关键信息，更不用说设备和应用程序了。封面是一只精美的动物，也是一本环保的书。（阅读本文，您将获得第一个支持；）

【解决方案2】：

没有。

我可以将任何我想要的标头模拟为恶意攻击者。我可以让它看起来像是来自http://cia.fbi.gov.vpn/uber1337h4x。这是显而易见且众所周知的。
来自HTTPS 的任何页面都不会按照RFC2616 sec15 发送引用标头：

如果引用页面是使用安全协议传输的，则客户端不应在（非安全）HTTP 请求中包含 Referer 标头字段。
根据RFC2616 sec15 破坏可用性：

由于链接的来源可能是私人信息或可能会泄露其他私人信息源，因此强烈建议用户能够选择是否发送Referer字段。

简而言之，您没有获得更高的安全性。您的安全性不在于检查非常不安全的传输协议，而在于 OAuth 层。你也会破坏可用性。

别这样。

【讨论】：

绝对没有更高的安全性。事实上，我没有在我的问题中提到安全这个词。只是“利益”。我正在使用状态来保证安全，这已经足够好了。鉴于拒绝服务攻击，我确实使用了“合法”一词。是的，它们可以被伪造，而且您提到 https 没有引用者，这使得任何主流提供商都不太可能返回引用者。由于本质上内容与另一个答案相同，因此我更倾向于接受较早的答案。但是，无论如何，你有我的赞成票。
@agksmehx 引荐来源标头可能传达哪些有益信息表明状态参数的存在已经不存在？
@Esailija，请看我自己的回答。
攻击的目的是让用户使用攻击者的token执行请求：攻击者发送一个URL给用户，用户访问该URL。因此，攻击者可以不控制用户发送的 Referrer 标头。检查 Referrer 标头（在发帖人的问题中）的目的是防止毫无戒心的用户将攻击者的令牌与他/她的帐户相关联。

【解决方案3】：

答案是：

No, you shouldn't use it, and there is NO valuable benefit of doing it.

授权服务器也非常清楚这一点。并且声明了here。

来自mailing list of OAuth-WG：

回调 URL 页面应该在收到 URL 中的授权代码后立即重定向到受信任的页面。这可以防止授权代码保留在浏览器历史记录中，或无意中泄漏到引用标头中。

如果您担心 CSRF，则不应使用 HTTP Referer 作为验证授权来源的技术，这就是参数 state 的原因（您使用的是哪个声音）。
如果您担心 oauth2 协议的特定安全问题，可以使用full section inside the draft。
如果您担心其他安全注意事项，this is the source。

我建议你全力以赴实施围绕参数的所有验证：state。

编辑：

阅读问题的细微差别后，you are really answered 您自己的问题。在这两种情况下使用 cookie（可能是 HTML5 本地存储）是我们目前所知的最佳解决方案。

第一个细微差别是关于 CSRF 的，其中一个可能的对策是 Checking the HTTP Referer header，而这已经是 addressed in the protocol。

第二个细微差别，我不能完全确定，但可能是 Extension Grant 的情况，这是因为听起来你可以作为“身份验证代理请求者”工作，与 SAML oauth2 extension 相同。

【讨论】：

嘿，感谢您的出色回答。您能否看看我自己的答案，并可能将您的答案与我的答案联系起来？我不知道会话固定一词（可能不知道其他用户）。我有点觉得您正在解决我在自己的答案中遇到的问题，因此，如果您可以添加更多解释，我愿意接受您的回答。谢谢！ :)
我正在授予赏金，因为它很快就会到期。我希望你能编辑答案（也许与我的合并），所以我也可以接受。谢谢！

【解决方案4】：

简单的安全性不是问题的关注点，因为正在使用state 参数。

我想到的主要问题是：

是否是我的应用发送到 Facebook 的浏览器返回来提供候选令牌？
代理（类似浏览器的代理）或代理是否反复执行 OAuth 请求并向我显示错误的 OAuth 令牌，导致我的应用反复使用错误令牌与 Facebook 联系，从而可能导致 Facebook 的不利处理。

第一个问题的唯一可能解决方案是除了使用state 之外还设置一个cookie。如果大多数提供商不使用 https，referer 会有所帮助。

第二个问题有细微差别。行为不端的代理不需要由恶意实体直接控制。它们可能是通过某种间接方式（流行的被劫持网站、社会工程）重定向的普通用户浏览器。

由于细微差别，referer 标头可能不是伪造的。但是，https 排除了任何有意义的好处。

Cookie 在第二种情况下肯定有帮助，因为如果您在 POST 中设置 Cookie，则任何第三方网站都无法设置它们，并且您不会因为被黑客网站将用户大量重定向到 OAuth 而被糟糕的 OAuth 响应淹没你。

这不是一个明确的答案（或问题），但希望这能说明问题背后的细微差别。

【讨论】：