1. 首看看漏洞的起因：

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

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

http://sdfa.com@chillyc.info?blog.csdn.net/

这些 Url 在不同的浏览器上表现可能不太一致。但是我在 Chrome上，输入第一个url 调整到了 chillyc.info的一个404页面。但不管怎么说，大多程序员使用找到 ‘.‘ 和‘/‘来判断domain的方法十分不靠谱。so~~~~为什么呢？写这些Oauth的家伙们都没有看过RFC 3986 (Uniform Resource 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协议中这种漏洞不会造成威胁。