针对近期“博全球眼球OAuth漏洞”的分析与防范建议
据Cnet报道，新加坡南洋理工大学一位名叫Wang Jing的博士生，发现了OAuth和OpenID开源登录工具的“隐蔽重定向”漏洞(Covert Redirect)。
首先需要明确的一点是，漏洞不是出现在OAuth 这个协议本身，这个协议本身是没有问题的，之所以存在问题是因为各个厂商没有严格参照官方文档，只是实现了简版。 问题的原因在于OAuth的提供方提供OAuth授权过程中没有对回调的URL进行校验，从而导致可以被赋值为非原定的回调URL，就可以导致跳转、XSS等问题，甚至在对回调URL进行了校验的情况可以被绕过，具体将在附件中的paper中阐述。
微博安全团队4 月中旬已经率先发现该问题，并联合业务部门进行威胁的评估和落地修复方案的敲定，截止今天中午前，回调URL校验和校验绕过漏洞在开放平台已经修复上线。
来看看来自知道创宇安全研究团队Fooying与Erevus同学执笔的paper吧，针对近期“博全球眼球的OAuth漏洞”的分析与防范建议 。
鸣谢来自微博安全团队同学的帮助。
1. OAuth介绍
1.1. OAuth简介
来自OAuth的官网解释：
An open protocol to allow secure authorization in a simple and standard method from web， mobile and desktop applications.
OAuth is a simple way to publish and interact with protected data. It's also a safer and more secure way for people to give you access. We've kept it simple to save you time.
大概的意思是OAuth是一种开放的协议，为桌面程序或者基于BS的Web应用提供了一种简单的，标准的方式去访问需要用户授权的API服务。OAuth是一个发布并与受保护数据交互的简单方法。这也是一个更安全的访问方式。我们已经保持它的简单来节约您的时间。
简单的说，OAuth就是第三方的应用可以通过你的授权而不用知道你的帐号密码能够访问你在某网站的你自己的数据或功能。像weibo、QQ、淘宝等网站都提供了OAuth服务，提供OAuth服务的网站一般都有很多开放的API，第三方应用会调用这些API来开发他们的应用以让用户拥有更多的功能，但是，当用户在使用这些第三方应用的时候，这些第三方的应用会来访问用户的帐户内的功能和数据，所以，当第三应用要干这些事的时候，我们不能让第三方应用弹出一个对话框来问用户要他的帐号密码，不然第三方的应用就把用户的密码给获取了，所以，OAuth协议会跳转到一个页面，让用户授权给这个第三方应用以某些权限，然后，这个权限授权的记录保存在提供OAuth服务的网站上， 并向第三方应用返回一个授权token，于是第三方的应用通过这个token来操作某用户帐号的功能和数据时，就畅通无阻了。
这其实是一个授权操作的过程，用户注册帐号的网站（如微博等）提供OAuth服务，第三方服务想调用用户对应帐号的相关信息做帐号相关的操作，就会请求OAuth提供方的授权，当OAuth提供方询问用户并得到授权，就会给予第三方服务一些权限做相对应的操作。
1.2. OAuth 2.0
OAuth分为OAuth以及OAuth 2.0。OAuth Core 1.0 版本发布于2007年12月4日，由于存在可被会话定向攻击(session fixation attack)的缘故，2009年6月24日发布了OAuth Core 1.0 Revision A 版本。最终在2010年4月，OAuth成为了RFC标准： RFC 5849: The OAuth 1.0 Protocol。
OAuth 2.0的草案是在2010年5月初在IETF发布的。OAuth 2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。规范还在IETF OAuth工作组的开发中，按照Eran Hammer-Lahav的说法，OAuth于2010年末完成。
OAuth 2.0授权框架允许第三方应用程序获得指定HTTP服务的有限的访问权限。
1.3. 授权交互流程
OAuth的授权有四种方式，主流采用两种方式，分别是Authorization Code（response_type=code）与Implicit（response_type=token）。
Authorization Code方式授权交互：
与Implicit方式授权交互：
2. OAuth与OpenID登录工具漏洞
2.1. 漏洞发现与报道
据Cnet报道，新加坡南洋理工大学一位名叫Wang Jing的博士生，发现了OAuth和OpenID开源登录工具的“隐蔽重定向”漏洞(Covert Redirect)。
这可导致攻击者创建一个使用真实站点地址的弹出式登录窗口——而不是使用一个假的域名——以引诱上网者输入他们的个人信息。
鉴于OAuth和OpenID被广泛用于各大公司——如微软、Facebook、Google、以及LinkedIn——Wang表示他已经向这些公司已经了汇报。
Wang声称，微软已经给出了答复，调查并证实该问题出在第三方系统，而不是该公司的自有站点。
Facebook也表示，“短期内仍无法完成完成这两个问题的修复工作，只得迫使每个应用程序平台采用白名单”。
至于Google，预计该公司会追踪OpenID的问题；而LinkedIn则声称它将很快在博客中说明这一问题。
该中文版来自：http://digi.163.com/14/0503/08/9RACJBK900162OUT.html，
原英文版：http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/
2.2. 漏洞说明
首先需要明确的一点是，漏洞不是出现在OAuth这个协议本身，这个协议本身是没有问题的，之所以存在问题是因为各个厂商没有严格参照官方文档，只是实现了简版。
微博安全团队4月中旬已经率先发现该问题，并联合业务部门进行威胁的评估和落地修复方案的敲定，截止今天中午前，回调URL校验和校验绕过漏洞在开放平台已经修复上线。
3. 漏洞成因、利用及危害
3.1. 漏洞利用
部分OAuth 2.0提供未对回调URL进行校验甚至校验可以被绕过的情况下，黑客可以通过构造钓鱼页面，用户在访问了黑客构造的页面之后，可以被获取OAuth授权中最终返回的token，通过token可以实现登陆该用户的第三方应用或者是调用OAuth提供的API进行相关操作，包括获取在OAuth提供方注册的相关资料等。
3.1.1. 回调URL未校验
如果回调URL没有进行校验，则黑客可以直接修改回调的URL为指定的任意URL，即可以实现跳转甚至是XSS。
如：
3.1.2. 回调校验绕过
部分OAuth提供方在进行的回调URL校验后存在被绕过的情况。
如：
未进行绕过修改回调URL提示校验失败
绕过后后修改URL校验成功。
3.1.3. 利用第三方应用漏洞
这其实也属于校验不完整的而绕过的一种情况，因为OAuth提供方只对回调URL的根域等进行了校验，当回调的URL根域确实是原正常回调URL的根域，但实际是该域下的一个存在URL跳转漏洞的URL，就可以构造跳转到钓鱼页面，就可以绕过回调URL的校验了。
如：
3.1.4. 授权验证参数的不正确使用
部分第三方应用在授权过程中采用如state里包含access token接收的回调URL，但是因为OAuth提供方只对回调URL，即参数redirect_uri的值进行校验，就可以导致黑客可以随意构造回调的URL，就导致问题的出现。
3.1.5. 绕过方式
1) redirect_uri=http%3A%2F%2Fwww.a.com?www.b.com
2) redirect_uri=http%3A%2F%2Fwww.a.com\.www.b.com
3) redirect_uri=http%3A%2F%2Fwww.a.com:\@www.b.com
其中www.a.com为钓鱼或者接收token的页面，www.b.com为实际回调的URL
3.2. 漏洞危害
3.2.1. URL跳转
黑客可以利用该问题构造相关的钓鱼页面，诱使用户访问从而造成用户的帐号被窃取等相关损失等。
3.2.2. API调用
因为黑客可以通过给问题获取到用户的相关授权token，可以通过token调用OAuth提供方的相关API方法进行相关的操作，包括获取用户资料、发表微博等等（如腾讯API调用可以参考http://wiki.open.qq.com/wiki/API%E5%88%97%E8%A1%A8）。
3.2.3. CSRF
利用CSRF技巧进行隐蔽攻击，可以获取到用户的token，然后使用token调用相应开放平台的API接口，登陆第三方应用并对用户的账户进行相关操作。
这意味着黑客可以通过该问题构造对用户进行钓鱼甚至是获取用户的注册资料、登陆用户帐号进行相关操作等。
4. 漏洞影响
通过对国内部分提供OAuth 2.0的网站进行测试和调查，发现均不同程度的存在以上的问题。
| OAuth提供方 | 回调URL校验 | 可利用第三方应用漏洞 | 校验绕过 |
| 新浪微博 | 是 | 是 | 是（已修复） |
| 百度 | 是 | 否 | 未测试 |
| 腾讯 | 是 | 是 | 是（已修复） |
| 360 | 是 | 未测试 | 未测试 |
| 开心网 | 否 | 是 | |
| 人人网 | 是 | 是 | 未测试 |
| 淘宝网 | 是 | 是 | 未测试 |
| 天涯 | 否 | 是 | |
| 搜狐 | 否 | 是 | |
| 网易微博 | 否 | 是 |
从测试结果可以看出，除了百度绕过未进行测试外，其他都存在问题，而且好几个甚至对回调URL都没有进行校验，而对回调URL进行校验了的又可以被绕过。
5. 漏洞防范
5.1. OAuth提供方
1) 对redirect_uri进行全路径验证，避免URL跳转情况
2) 参数state即用即毁
3) 首次授权，强制验证
4) 获取access_token，验证App secret
5) 回调URL进行跳转校验等
6) 加强redirect_uri验证，避免绕过
5.2. 普通用户
对于普通用户来说，其实没有什么好恐慌的，这次问题的利用的前提是对构造URL的访问，所以主要是针对URL提高警惕和识别，需要注意以下几点：
1) 只授权给可信的第三方应用
2) 不要访问不明来路的链接，正常的应用授权应该是通过页面中的登陆按钮等方式进行的。
PDF版下载地址：针对近期“博全球眼球OAuth漏洞”的分析与防范建议
附录
7条评论
asfasfasdfasf
看了博主的文章，真的很有收获啊http://www.xiaotaoyongyi.com
都不是什么大事，只不过比较关注而已。上海贷款公司http://shanghai.yiqirong.com/
非常专业，不错
Cnet就是个媒体，这新闻真是用来博眼球的。这个所谓的漏洞哪比得上heartbleed呢。
我把所有的技术资料读了一遍，现在仍然觉得仔细地检查state参数，理顺认证流程是可以防御这类攻击的。
第三方应用不能假设授权重定向页面不被泄露，因为它是HTTP GET的，所有的参数很容易被窃听到。最重要的是检查state的逻辑，因为开发平台文档的简化和第三方工程师的粗心，检验state的逻辑如果不在后端有session检查，就会有漏洞。知道创宇给出的防御建议撇清了第三方应用的责任，我觉得是不恰当的。真正重要的是，第三方要假设授权重定向这个页面可能被泄露，然后根据这个安全边界来校验state参数。
原则上，即使code被泄露，攻击者不知道secret和对应的state也是无法实现攻击的。