OAuth 漏洞预警 (OAuth平台redirect_uri 漏洞)

1. 首看看漏洞的起因:

有兴趣的你可以将下面的url贴到浏览器看看效果:

1
http://chillyc.info\.csdn.net  

或者这个url:

1
http://[email protected]?blog.csdn.net/

这些 Url 在不同的浏览器上表现可能不太一致。但是我在 Chrome上,输入第一个url 调整到了chillyc.info的一个404页面。但不管怎么说,大多程序员使用找到 '.‘和’/'来判断domain的方法十分不靠谱。so~~~~为什么呢?写这些Oauth的家伙们都没有看过 RFC 3986 (UniformResource Identifier (URI): Generic Syntax) .  或者看了一眼发现:我x,这么多英文。然后就跳过了。不过不光中国人实现的有问题, 各种版本浏览器实现的也都有些问题。也有可能大家都觉得不会有这么复杂的uri。

2. 对于Oauth平台来说如何修补漏洞?

好吧,下面看了下rfc,简单介绍一下uri的定义:

给大家一个rfc上的正则福利,这个正则是为了匹配上面的uri的定义。

下面是这个正则对url进行解析:


好吧。那除了Oauth平台用这个正则来真正找到domain还有什么更简单的方法来预防这个漏洞吗?嗯,其实加盟的第三方一开始只要遵循了Oauth2.0的规范。还是比较容易预防这个漏洞的。

3. 再简单介绍下Oauth2授权 :

针对Oauth2协议, Oauth2中有几种获取 accessToken的方式(就是response_type 这个域):

1. code, 这种是先获取到 code, 然后再用code 来获取accessToken

2. token, 这种是直接获取到accessToken ,这个比code更加直接。

而对于token这种方式进行授权的。 就会带来比code方式更加危险的问题。 造成这个问题的原因就是 redirectUrl 这个参数的domain在各大平台上判断的都有问题。 原因也很简单,大家都觉得这东西安全不是那么重要, 都https, 还在意什么安全问题。 另外授权流程那么的复杂,谁在意这鬼东西还能出来什么安全问题。再说即使是有问题,那肯定第三方自己就能修复,完全不需要各大平台修复。各大平台只需要保证你发来正确的信息,给你正确的返回就行了。所以这个漏洞等级很低。

但是这个漏洞,的确可以将code 或者 accessToken通过这个漏洞发送给恶意第三方。特别是第二种使用token的直接授权方式。除非Oauth平台修改。加盟的第三方应用无法做出有成效的修补。所以我下面只介绍使用第一种授权方式code的修补方案。

4. 加盟第三方如何修补和预防

首先,你这个应用需要是 Server应用(有自己的服务器或者有后台不可见代码)。 JS的app完全预防不了(之前指定Oauth2.0时说各个浏览器都要出份力,但好像也没有见到这对JS app的Oauth2.0有什么改进之处。)只要代码可见,不管明文密文,都一定是能获取到该应用的appKey和appSecret的。所以怎么都能获取到用户真正的accessToken,不管是钓鱼还是伪造。

不考虑直接客户端获取accessToken的形式。 Oauth说白了就是 Oauth平台和Server之间通信。如下图:


下面我们考虑浏览器:


下面我们考虑一下恶意程序,恶意程序只会出现在两个地方。一个是以脚本的形式出现在浏览器中(见恶意程序1)。另外一个是让信息流强制流向恶意服务器(见恶意程序2)。


下面我们分别就两个恶意程序来讨论一下如何修补规避漏洞。

  • 对于恶意程序1, 这里最简单的做法就是让JS只知道部分信息。例如登录中常用的shadow cookie的方法。JS用于显示用户名或者登录信息的cookie 不是httpOnly的,而真正作为服务器认证凭证的cookie则使用httpOnly cookie。这样恶意的JS无法获取到真正有用的cookie. 详见 Cookie的特性
  • 对于恶意程序2,这里需要在我们的server请求Oauth平台时,首先植入一个认证信息,例如cookie/session等。即使通过url漏洞跳转到恶意程序2, 恶意程序2这时可以获取到Oauth平台发来的code和state. 而浏览器通过cookie的domain属性保证开始植入的认证信息不会发送给恶意程序2.
    • 恶意程序2 通过其他方式和我们的server进行交互时,因没有认证信息,我们的server不会返回给它accessToken。

    • 恶意程序2 直接和Oauth平台交互,因为没有appSecret和appKey, 也无法获取到accessToken.

5. 结论

做了以上两步,redirect_uri的漏洞不管怎么样,都只能称为Oauth平台的bug。而你的服务是足够安全的。上面的安全是基于电脑没有中病毒,以及服务自身没有其他的隐患的假设。顺便一提,oauth2中redirect_url漏洞才会造成威胁。Oauth1.0a协议中这种漏洞不会造成威胁。