介绍
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码)，即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。oAuth是Open Authorization的简写。
OAuth认证原理
OAuth 2.0中有6种常用的授权类型:
-
Authorization Code
-
Implicit
-
Password
-
Client Credentials
-
Device Code
-
Refresh Token
本文只介绍其中的Authorization Code(授权码模式),这也是目前国内大部分厂商使用的模式
你可能之前并没听过OAuth这个词,但一定已经使用过它了
例如新浪微博这里就提供了多种第三方登陆,下面笔者以”用QQ号登陆新浪微博”这个实例来讲解OAuth认证的原理
我们把”微博”称作客户端,”QQ”称作服务端
点击QQ登陆的图标,用户将被导向服务端的认证服务器
用户在此选择是否给予客户端(微博)授权,如果授权,则客户端将会获得用户在服务端(QQ)的昵称,头像和性别资料
先来看下这个URL
这其中有重要意义的参数有以下几个:
-
client_id
客户端标识,这个参数是和客户端一一对应的,这样服务端才知道认证请求来自哪个客户端.例如”101019034”代表的就是新浪微博这个客户端
-
response_type
授权类型,上文已经说了OAuth有多种授权类型.此处”code”代表使用的是Authorization Code(授权码模式)
-
scope
申请的权限范围
-
redirect_uri
重定向URI,用户给予授权后,将会携带授权码跳转到此地址
-
state
这个参数是用来防御CSRF的,你可以将其理解为我们常用的”token”.这里它的使用和”token”也是一样的
每次授权请求,客户端都会生成一个state,并将其保存到cookie或session中.授权成功后,服务端原样返回state,客户端将其与cookie或session中的值进行比对
回到授权过程,如果用户点击了QQ头像确认授权
认证服务器确认用户身份后,会生成一个授权码(code),然后将用户导向之前redirect_uri指定的地址,并附带上授权码(code)和state
state的作用已经说过是防御CSRF的,最终要的就是这个code了
客户端收到授权码(code)后,将其发送到服务端比对(这一步在客户端后台服务器完成,对用户不可见)
如果比对结果一致,那么游戏结束
在这个请求中,比对结束后,生成了一个alt,并跳转到了login.sina.com.cn域
验证了alt后,就在.sina.com.cn域种上cookie了.
从这个登陆案例来看,只要攻击者拿到了code参数,那么就能劫持用户的微博账号.
有经验的攻击者一定发现了,既然code参数会发送到redirect_uri参数指定的地址,那么只要让redirect_uri跳转到我们指定的地址,那么就能窃取code.
OAuth几个案例
案例1 新浪微博登陆劫持
redirect_uri限制不严格,可跳转到任意子域
虽然redirect_uri不能任意指定,但是微博的业务设定为了可以跳转到任意weibo.com的子域下.
如果我们能在某个子域下的某个页面引入外部资源(img,vedio的href属性;script标签的src属性),再让redirect_uri携带code跳转到这个页面,那么我们就能从referer头里窃取到code.
你可能首先会想到XSS,但是现在XSS不是那么好找了,而且用在这里有点大材小用.其实只要我们能引入一个外部图片就行了.
这种功能很常见,很多地方都允许插入在线图片.
我在xxx.weibo.com域下的一个帖子里插入了一个在线图片,图片地址填ceye平台地址.
然后修改redirect_uri为该帖子的地址.
然后把这个链接发给受害者,一旦他点击头像确认登陆,携带code的请求就会被导向到攻击者引入了外部图片的页面.
页面加载了img标签后,code就会通过referer头泄露出去.
上文已经说过,只要攻击者拿到code,那么发送给passport.weibo.com进行认证,就能劫持用户的微博账号了.
案例2-某厂登陆劫持 "案例2 某厂登陆劫持")案例2 某厂登陆劫持
redirect_uri严格限制,但目标域不安全
看了案例1,你可能会觉得应该由xxx.weibo.com背锅,如果严格限制redirect_uri跳转到指定域,就不会由问题了.
这是在一次众测遇到的一个案例,貌似还没修复,就不说名字了.
该厂允许绑定淘宝账号进行第三方登陆,
并且严格限制了只能跳转到a.xxx.com域下,所以上面那种随便找个子域插入图片的套路看来是不行了.
但不幸的是,我正巧的a.xxx.com域下找到一个XSS,
所以,我们能更方便的写入img或者scritp标签了,后面窃取code的方法和上面一样,就不多说了.
案例3 360 OAuth服务端漏洞
攻击OAuth服务端,一锅端
通过上面2个案例,我们可以得出这样的结论:
不仅要严格限制redirect_uri跳转的域,而且要保证其跳转到一个安全的域.
但是,人在广东已经….啊不对,人在家中坐,锅从天上来.
360作为服务端为其它厂商提供了OAuth认证的功能,开发者可以在360应用开发平台进行申请.
人家不仅提供了详细的开发文档,还给开发者弄了个调试工具.
理论上呢,redirect_uri是开发者自己填的,为了安全,只能是某个安全的域名.
但是,360为了便于开发者进行登陆调试,把”openapi.360.cn”这个域名设置成了所有应用的合法回调地址.
那么openapi.360.cn这个域的安全性直接影响到所有客户端.
不幸的是,我又在openapi.360.cn下找到一个XSS,
所以,又能快乐的窃取到code了,并且影响了所有使用360账号登陆的应用.
总结
关于OAuth认证,还有其它的授权类型以及各种漏洞有待探索.
对于本文提及的授权码模式,其中的redirect_uri参数应该有以下递进式的限制:
- 跳转到专门的认证服务器域名
- 跳转到该域名下某个确定的页面
- 确保该页面是安全的(无法引入外部资源)
参考
https://tools.ietf.org/html/rfc6819
原文：
https://03i0.com/2018/04/01/OAuth回调参数漏洞案例解析/
