OAuth研究&学习笔记

一直都是知道OAuth就是这么一个认证授权的协议,也没好好的深入研究学习下,昨晚鹅厂的模拟考,啪啪啪打脸!!!感觉答得一般,还好之前看过乌云的文章,多少会写一点,不过感觉还是不够啊。。遂就此文hhhh

2

0x00 什么是OAuth?


(一)OAuth应用场景
先了解下什么是OAuth(Open Authorization),顾名思义是一种开放授权协议,简单的说,假设用户小明在A公司的云服务上存放了多份公司文档,其中一份需要使用B公司的云打印服务完成,在没有OAuth之前,小明需要将该份文档从A下载下来再上传给B,或者把用户名和密码告诉B,由B自取;但是这样的问题很明显的就是B有可能盗取小明的商业机密文档,在这种场景下,OAuth协议就应运而生了;现如今大部分的第三方登录,便是使用了这种协议,方便用户的同时也是大大地提高了安全性。

(二)OAuth1.0相关参数
1.三个URL
Request Token URL: 获取未授权的Request Token服务地址;
User Authorization URL: 获取用户授权的Request Token服务地址;
Access Token URL: 用授权的Request Token换取Access Token的服务地址;
2.常见参数(详细点我)
consumer_key: 第三方应用软件的ID。所以该参数值的获取一般是要去OAUTH服务提供商处注册一个应用,再获取该应用的consumer_key。
consumer_secret:consumer_key对应的密钥。
token:OAUTH进行到最后一步得到的一个“令牌”,通过此“令牌”请求,就可以去拥有资源的网站抓取任意有权限可以被抓取的资源。
token_secret:token对应的私钥。
signature_method: 请求串的签名方法,应用每次向OAUTH三个服务地址发送请求时,必须对请求进行签名。签名的方法有:HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种。
signature: 用上面的签名方法对请求的签名。
(三)OAuth1.0认证授权流程
1.获取未授权的request token
2.获取用户授权的request token
3.用授权的request token换取Access Token
4.访问受保护资源
具体步骤如下:
A. 使用者(第三方软件)向OAUTH服务提供商请求未授权的Request Token。向Request Token URL发起请求。
B. OAUTH服务提供商同意使用者的请求,并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret,并返回给使用者。
C. 使用者向OAUTH服务提供商请求用户授权的Request Token。向User Authorization URL发起请求,请求带上上步拿到的未授权的token与其密钥。
D. OAUTH服务提供商将引导用户授权。该过程可能会提示用户,你想将哪些受保护的资源授权给该应用。此步可能会返回授权的Request Token也可能不返回。
E. Request Token 授权后,使用者将向Access Token URL发起请求,将上步授权的Request Token换取成Access Token。
F. OAUTH服务提供商同意使用者的请求,并向其颁发Access Token与对应的密钥,并返回给使用者。
G. 使用者以后就可以使用上步返回的Access Token访问用户授权的资源
如图:

12

再来张中文的:

121

(四)OAuth2.0四种授权模式
1.授权码模式(Authorization Code)
授权码是从第三方OAuth服务提供商获取,而不是直接从资源拥有者获取。
2.隐式模式(Implicit)
该模式是一种简化的授权码模式,针对在浏览器使用脚本语言的客户端,该模式直接发布一个access token
3.资源所有者密码凭据许可(Resource Owner Password Credentials)
通俗地说就是将用户密码提供给第三方,但是对第三方应用采取访问控制,只有高度信任的情况才允许高权限
4.客户端凭证许可(client credentials)
这种模式限制条件比较多,比如资源拥有者就是客户端本身,或者请求的资源已经被保护,这时可以使用客户端凭证登录

0x01 OAuth安全


(一)OAuth1.0安全问题
A.会话固定攻击
1.0最常见的就是会话固定攻击(Session Fixation Attack);由于没有对oauth_callback进行检查和限制,也没有任何机制保证整个授权流程只由一个人完成,因此造成了该安全问题,导致攻击者可以访问目标用户的资源。

3

安全案例: WooYun-2010-00781
B、平台授权页面csrf
漏洞成因:
(A)攻击者从应用方预先获取带REQUEST TOKEN参数的授权认证页面url,但并不跳转,而是记录下原来的oauth_callback参数,并将其替换成攻击者的url。

(B)受害者访问该恶意构造的授权认证页面url后,使用自己的平台方账号进行授权。完毕后平台方根据oauth_callback,连同REQUEST TOKEN等参数,指示受害者浏览器跳转到攻击者的url。

(C)攻击者打时间差,抢先访问原来的oauth_callback参数,至此成功登录到受害者的应用方账号上。整个过程不需要知道APP SECRET和REQUEST TOKEN SECRET,也可以bypass应用方的csrf防御。
漏洞案例:
WooYun:网易开放平台第三方应用oauth强制用户授权漏洞

(二)OAuth2.0安全问题

1、授权码模式安全问题分析

A、CSRF劫持第三方账号
漏洞成因:
redirect_uri中的code参数没有和当前客户端的状态绑定,攻击者可以通过发送预先获取好的code参数到受害者电脑,导致导致受害者当前登录的应用方账号被绑定到攻击者指定的平台方(如微博)帐号上。
漏洞案例:
WooYun:大麦网存在账号被劫持风险
WooYun:美丽说oauth漏洞可劫持账号
B、对参数没有进行验证泄露code
漏洞成因:
因为对场景考虑不周导致的OAuth 2.0协议实施不全面,没有对参数进行确认,没有防止参数被篡改
漏洞案例:
WooYun:腾讯微博开放平台openid、openkey截取
WooYun:搜狐微博OAuth2.0获取Authorization Code过程隐患
C、重放攻击
漏洞成因:
平台如果对code是固定的,那么容易被获取,并重新使用
漏洞案例:
WooYun;Inwatch-InHealth客户端接口若干安全bug打包

2、隐式模式安全问题分析

A、模式本身缺陷容易导致token泄露
漏洞成因:
授权验证时只需要client_id和redirect_uri这两个参数作应用标识,返回的时候也就直接在uri片段中返回access token,客户端难以保密双secret(app secret,access token secret)也难以加密。
漏洞案例:
WooYun:QQ互联开放平台QQ登陆oauth授权接口可以劫持access_token
WooYun:人人网Oauth 2.0授权可导致用户access_token泄露
B、应用冒充,获取token控制用户账户
漏洞成因:
攻击者只使用公开参数用就能冒充成其它应用调出授权页面,获取到的access token可以用于控制受害者的平台方账号。如果是高权限client_id,获取到的access token显然更有破坏力。
漏洞案例:
@囧虎张建伟,新浪微博Android客户端SSO授权认证缺陷
WooYun:腾讯开放平台单点登录SSO方案设计缺陷导致钓鱼风险

3、资源所有者密码凭据许可模式安全问题

A.XAuth;直接用平台方用户名和密码获取access token
漏洞成因:
XAuth是由应用方代为提交用户名和密码到接口,而绕过了平台方本身的授权认证页面,在无法确保应用方能力信誉和安全状况的情况下,难以保证用户名和密码不会被泄露。用户输入平台方账号和密码后,通过应用方服务器同步登录到平台方和应用方账号。但这种设计流程,很容易在传输到应用方网站的过程、乃至在应用方服务器上就泄露了账号密码等敏感信息。
漏洞案例:
WooYun:开心网android客户端暴力破解漏洞,测试2000帐号,成功132个
315晚会:安卓系统手机应用软件严重窃取用户资料

0x10 其他安全问题分析


1.高权限client_id(appkey)和client_secret(app secret)泄露
2.中继平台泄露token
3.绕过redirect_uri认证
4.api接口和主业务流的失调
5.攻击api接口或者配套系统
详见下面参考资料

0x11 参考资料


OAuth 2.0安全案例回顾
OAuth 安全指南
pnig0s《OAuth Security》
The OAuth 2.0 Authorization Framework
RFC6750.zh-cn

本文属于原创,转载请注明来自tasfa.cn 有问题请联系管理员root@tasfa.cn

发表评论

电子邮件地址不会被公开。

You must enable javascript to see captcha here!