手机应用中的OAuth登陆安全测试

gclome

原文链接：手机应用中的OAuth登陆安全测试

效果展示

鉴于本文写的太乱，实在怕有些同学因保护视力而不继续看下去，先放出通过后文描述的两种方法挖掘到的一小部分漏洞作为吸引。
​
​
​
OAuth2授权访问之implicit模式
首先来看下OAuth的定义：OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。
在大家测试过程中，常见到的快捷登录都是授权码模式（authorization_code），也就是应用（QQ/微博）给出授权码code，服务端通过code换取access_token，再继续进行下一步请求。
以我们外部的视角来看，大致流程如下：
​

访问网站a，选择微博快捷登录，跳转到api.weibo.com，微博用户点击授权，然后会从api.weibo.com携带code参数跳转回网站a，我们的应用a.com得到了code就会在后端调用第三方提供的api去获取uid、access_token，这里参照微博给出的api文档（https://weibo.com/login.php）
下一步就可以继续通过access_token去请求第三方的其他api，来看一下account/get_uid（https://open.weibo.com/wiki/2/account/get_uid）
​

如上图，通过access_token请求该接口即可返回uid。
上面的描述，全部都是关于授权码模式，实际上implicit模式和授权码模式非常相似，只不过缺少了一个code =》access_token的步骤，第三方会直接提供access_token给开发者使用，不再给出code。
1.未对微博的access_token校验导致任意用户登陆
这个问题在多个app中见到了，我测试过的应用中大约有10%的app存在该问题，一旦出现后果就会很严重。这种利用方法，针对有微博快捷登陆的应用。

app中的微博快捷登陆是通过调起微博app请求https://api.weibo.com/oauth2/sso_authoriz，然后获取这个请求的返回access_token和uid，所以对于app中的微博快捷登陆并不存在code这一说法，这也就是我们第一段提到过的implicit模式。获取access_token的请求如下：
​

多数的应用会获取返回的access_token然后使用微博的api进行操作，但是应用只获取了uid而不去校验access_token然后就代入数据库进行查询，那么就存在一个任意登陆的问题。
一个案例：
在这个应用内点击微博快捷登陆，然后调起微博app，注意到上面截图的https://api.weibo.com/oauth2/sso_authoriz请求，修改该请求返回的uid后放行后面的全部请求即可。
​
此时已经越权登陆了该微博绑定的账号，所有功能可用。
原因如下，注意到在应用中的请求中有一个：https://victim.com/user/thirdapp/login，
​

这是最关键的一个set-cookie的请求，其中请求参数open_id就是刚刚返回的微博帐号的用户uid，也就是刚刚我们修改的返回包的数值。
微信快捷登陆也是这种
微信快捷登陆也是这种implicit模式，但是这种攻击方法并不适用于微信快捷登陆，首先微信帐号的open_id不是公开内容，当然如果你想到可以自己搭一个第三方登录的平台，来获取微信用户的open_id也是不行的，因为同一个微信账号给不同的APP生成的open_id都是不一样的，所以无法利用，在这里给微信点赞。

这里补充一下如何获取指定微博账号的uid，查看用户页面的源代码搜索：$CONFIG['oid']
https://weibo.com/wflanker
​
修复方式：
如果一定要使用uid，使用此接口对access_token校验：https://open.weibo.com/wiki/Oauth2/get_token_info
​

请求获取返回的uid，不要相信用户输入给你的uid。

​

2.微博access_token校验不严格导致交互后劫持账号
这种问题存在于99%的应用内，这种利用方法，也只针对微博快捷登陆。这种问题的危害不如第一种明显，是一种需要交互进行的漏洞，随便提交了几家观察了一下厂商的反应，多数是中危，少数是高危，也有些厂商因为自己家有大量app存在该问题，打包提交，也能给出个高危的奖励。更多厂商的评级看各位的提交结果了～
当一个应用不存在第二个问题的时候并不一定完全没了风险，通过微博的官方调试平台（https://open.weibo.com/tools/console#）你看得出来每个微博api请求只需要一个access_token凭证就可以了，并不需要一些appid或者uid的信息。
其中有一些非常简单的请求，比如：
​

如果客户端获得了微博帐号的uid和access_token并进行了校验。但是如果只是通过这样类似的接口，通过access_token请求得到uid，然后就认为这个uid是我们的用户了，这样是不正确的。
先看一下利用方法如下：
我在微博开发者自建了一个应用是这样的
​
​
Oauth2.0授权回调页是攻击者的站点。
这里的快捷登陆链接就是：
https://api.weibo.com/oauth2/aut ... com%2f&state=30
登陆之后将会带着code进入百度（实际中是进入攻击者站点）：

​

通过官方手册，code是这样使用的：
​

此时攻击者获得了用户的access_token和uid
回到第一种利用方法：

​

这一次将access_token和uid同时进行替换就可以登陆别人绑定的帐号。
原因在于没有通过这一次将access_token和uid同时进行替换就可以登陆别人绑定的帐号。
原因在于没有通过https://open.weibo.com/wiki/Oauth2/get_token_info
获取appkey来校验这个access_token是不是真是由你的应用产生的。
1.访问攻击者的微博快捷登陆
2.攻击者获取code->获取access_token和uid
3.其他的应用帐号被劫持
修复方法：
通过https://open.weibo.com/wiki/Oauth2/get_token_info
获取appkey来校验这个access_token是不是真是由你的应用产生的。
​
最后
在当今，不管国内国外，几乎每一个站点都存在第三方快捷登录，国内主流的可能就是QQ/微博/微信，当然还是有其他的快捷登录方式，希望本文能够抛砖引玉，让各位同学能够发现更多种的快捷登录方式漏洞。

文章作者：DDDDD1，转载于先知社区