标签：安全 漏洞 redirect oauth cookie
有兴趣的你可以将下面的url贴到浏览器看看效果:
http://chillyc.info\.csdn.net或者这个url:
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。
好吧，下面看了下rfc,简单介绍一下uri的定义：
给大家一个rfc上的正则福利，这个正则是为了匹配上面的uri的定义。
下面是这个正则对url进行解析：
好吧。那除了Oauth平台用这个正则来真正找到domain还有什么更简单的方法来预防这个漏洞吗？嗯，其实加盟的第三方一开始只要遵循了Oauth2.0的规范。还是比较容易预防这个漏洞的。
针对Oauth2协议， Oauth2中有几种获取 accessToken的方式(就是response_type 这个域)：
1. code, 这种是先获取到 code, 然后再用code 来获取accessToken
2. token, 这种是直接获取到accessToken ,这个比code更加直接。
而对于token这种方式进行授权的。 就会带来比code方式更加危险的问题。 造成这个问题的原因就是 redirectUrl 这个参数的domain 在各大平台上判断的都有问题。 原因也很简单，大家都觉得这东西安全不是那么重要， 都https, 还在意什么安全问题。 另外授权流程那么的复杂，谁在意这鬼东西还能出来什么安全问题。再说即使是有问题，那肯定第三方自己就能修复，完全不需要各大平台修复。各大平台只需要保证你发来正确的信息，给你正确的返回就行了。所以这个漏洞等级很低。
但是这个漏洞，的确可以将code 或者 accessToken通过这个漏洞发送给恶意第三方。特别是第二种使用token的直接授权方式。除非Oauth平台修改。加盟的第三方应用无法做出有成效的修补。所以我下面只介绍使用第一种授权方式 code的修补方案。
首先，你这个应用需要是 Server应用（有自己的服务器或者有后台不可见代码）。 JS的app 完全预防不了（之前指定Oauth2.0时说各个浏览器都要出份力，但好像也没有见到这对JS app的Oauth2.0有什么改进之处。）只要代码可见，不管明文密文，都一定是能获取到该应用的appKey和appSecret的。所以怎么都能获取到用户真正的accessToken，不管是钓鱼还是伪造。
不考虑直接客户端获取accessToken的形式。 Oauth说白了就是 Oauth平台和Server之间通信。如下图：
下面我们考虑浏览器：
下面我们考虑一下恶意程序，恶意程序只会出现在两个地方。一个是以脚本的形式出现在浏览器中（见恶意程序1）。另外一个是让信息流强制流向恶意服务器（见恶意程序2）。
下面我们分别就两个恶意程序来讨论一下如何修补规避漏洞。
做了以上两步，redirect_uri的漏洞不管怎么样，都只能称为Oauth平台的bug。而你的服务是足够安全的。
上面的安全是基于电脑没有中病毒，以及服务自身没有其他的隐患的假设。顺便一提，oauth2中redirect url漏洞才会造成威胁。Oauth1.0a协议中这种漏洞不会造成威胁。
OAuth 漏洞预警 (OAuth平台redirect_uri 漏洞),布布扣,bubuko.com
OAuth 漏洞预警 (OAuth平台redirect_uri 漏洞)
标签：安全 漏洞 redirect oauth cookie
原文地址：http://blog.csdn.net/cctt_1/article/details/25145551
