我应该验证OAuth 2回调中的HTTP Referer吗？

Question

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

1. 如果我还检查HTTP Referer标头以确保从提供者的OAuth页面重定向,是否有任何好处？

2. 如果没有任何好处,如果我还检查HTTP Referer字段会有问题吗？

Answer 1

没有.

1. 我可以模拟我想要的任何标头作为恶意攻击者.我可以让它看起来像我来自http://cia.fbi.gov.vpn/uber1337h4x.这是显而易见的,众所周知的.

2. 来自的任何页面HTTPS都不会根据RFC2616 sec15发送引用标头:

   如果引用页面是使用安全协议传输的,则客户端不应在(非安全)HTTP请求中包含Referer头字段.

3. 根据RFC2616 sec15打破可用性:

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

简而言之,您没有获得更高的安全性.您的安全性不在于检查非常不安全的传输协议,而是在OAuth层中.你也打破了可用性.

不要这样做.

Answer 2

答案是:

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

授权服务器也非常清楚这一点.而在这里指出.

从OAuth-WG的邮件列表中:

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

• 如果您担心CSRF,您不应该使用HTTP Referer作为验证授权来源的技术,这就是参数状态(您正在使用的声音)的原因.

• 如果您担心oauth2协议的特定安全问题,草案中有一个完整的部分.

• 如果您担心其他安全注意事项,这就是源代码.

我建议你尽全力实现围绕param的所有验证:状态.

编辑:

在阅读了问题的细微差别后,您真的回答了自己的问题.在这两种情况下使用cookie(可能是HTML5本地存储)是我们目前所知的最佳解决方案.

• 第一个细微差别是关于CSRF,可用的一种可用对策是检查HTTP Referer标头,这已在协议中解决.

• 第二个细微差别,我不完全确定,但可能是Extension Grant的情况,这是因为听起来你可能作为"auth代理请求者"工作,与SAML oauth2扩展相同.