我可以使用我的Oauth2 servlet成功验证Facebook和Google帐户。我正在使用带有计时器和会话cookie的状态来尝试验证它确实是一个合法的Oauth回调。
如果我还检查HTTP Referer标头以确保从提供者的OAuth页面重定向，是否有任何好处？
如果没有任何好处，如果我也检查HTTP Referer字段会出现问题吗？
答案 0 :(得分：6)
没有
我可以模拟我想要的任何标头作为恶意攻击者。我可以让它看起来像是来自http://cia.fbi.gov.vpn/uber1337h4x。这是显而易见的，众所周知。
来自HTTPS的所有网页都不会按RFC2616 sec15发送推介标头：
如果使用安全协议传输引用页面，则客户端不应在（非安全）HTTP请求中包含Referer头字段。
根据RFC2616 sec15打破可用性：
由于链接的来源可能是私人信息或可能泄露其他私人信息来源，因此强烈建议用户能够选择是否发送Referer字段。
简而言之，您没有获得更高的安全性。您的安全性不在于检查非常不安全的传输协议，而是在OAuth层中。你也打破了可用性。
不要这样做。
答案 1 :(得分：5)
答案是：
No, you shouldn't use it, and there is NO valuable benefit of doing it.
授权服务器也非常了解这一点。并且here被陈述了。
回调URL页面在收到URL中的授权代码后，应该立即重定向到可信页面。这可以防止授权代码保留在浏览器历史记录中，或者无意中泄漏到引用标头中。
如果你担心CSRF，你不应该使用HTTP Referer作为验证授权来源的技术，这就是参数 state 的原因（听起来你是使用）。
如果您担心oauth2协议存在特定的安全问题，可以使用full section inside the draft。
如果您担心其他安全注意事项this is the source。
我建议你尽力实现围绕参数的所有验证：州。
修改
在阅读问题的细微差别之后，you are really answered您自己的问题。在这两种情况下使用cookie（可能是HTML5本地存储）是我们目前所知的最佳解决方案。
第一个细微差别是关于CSRF的，其中一个可能的对策是Checking the HTTP Referer header，这已经是addressed in the protocol。
第二个细微差别，我不完全确定，但可能是Extension Grant的情况，这是因为听起来你可以作为“auth代理请求者”工作，与SAML oauth2 extension相同
答案 2 :(得分：2)
不验证HTTP引用程序; “状态”参数（它听起来你正在使用）是approach OAuth 2.0 defines来抵御跨站点请求伪造（CSRF）攻击。
你可能想看看Ryan Boyd撰写的新O'Reilly书籍Getting Started with OAuth 2.0。它描述了这个和相关的安全性考虑。
答案 3 :(得分：-1)
普通安全性不是问题的关注点，因为正在使用state参数。
我心中的主要担忧是：
第一个问题的唯一可能解决方案是除了使用state之外还设置cookie。如果大多数提供商不使用https，referer会有所帮助。
第二个问题有一个细微差别。不正常行为的代理不需要由恶意实体直接控制。它们可能是通过某种间接方式（受欢迎的被劫持的网站，社会工程）重定向的普通用户浏览器。
由于细微差别，referer标题可能不会被伪造。但是，https排除了任何有意义的好处。
Cookie在第二种情况下肯定会有所帮助，因为如果你在POST中设置cookie，没有第三方网站会导致它们被设置，并且由于被黑网站将用户集中重定向到OAuth，你不会被糟糕的OAuth响应所淹没你。
这不是一个明确的答案（或问题），但希望这表明问题背后的细微差别。