授权登录的安全短板——[移动 APP 安全揭秘]第二期

前情提要

上期关键词回顾：网民吐槽的场景、障眼法的病毒、给他人做嫁衣的开发团队、见招拆招的乐固

上期阅读链接：[移动 APP 安全揭秘]第一期——泛滥的盗版

往事再现

两年前新加坡南洋理工大学一位名叫 Wang Jing 的博士生，发现了 OAuth 和 OpenID 开源登录工具的“隐蔽重定向”漏洞(Covert Redirect)，博足了全世界眼球，也被一些安全研究人员研究出了各种猥琐利用的方式（参看知乎专栏：优主张，OAuth 相关文章），能随意进出各大社交网站的用户主页，当时不少媒体以为是 OAuth 这个协议的问题，而实际 OAuth 这个协议本身是没有问题的，之所以存在问题是因为各个厂商没有严格参照官方文档，只实现了简版。

本期精彩

而 OAuth2.0 协议是目前被第三方登录服务商广泛采用的一个用于第三方授权的协议，有了上述的往年经验，第三方服务商在提供第三方登录服务时，也大多考虑到了可能存在的攻击面，因此更多的攻击点在 APP 自身。 继上期移动 APP 行业安全概况介绍后，本期我们跟大家重点讲讲 APP 中不安全的第三方登录实现方式，如何发现、如何避免 Appsecret 泄露（类似于授权密钥） 等，从而避免用户信息泄露，以及又将如何修复。

受开发者欢迎的第三方登录是什么？

现在市面上越来越多的 APP 或者 Web 应用都提供了第三方登录的功能，如通过微博、微信、QQ 登录等，用户只需要在对应的 APP 上选择授权就可以一键登录。

比起传统的账号密码注册登录流程，第三方登录减少了很多繁琐的操作和流程，降低了注册和登录门槛，并且更有安全保障，所以也很受开发者的欢迎。

然而即使第三方登录安全性已有保障，但正如木桶理论所说，决定产品安全性的往往是一些“短板”，如开发者对授权流程的错误理解，不正确的实现方式等。

 完整的第三方登录流程与 

     所使用的 OAuth 2.0 协议    

OAuth2.0 协议是目前广泛被采用的一个用于第三方授权的协议，具体的协议 RFC 文档可参看

• https://tools.ietf.org/html/rfc6749 

比起曾经的 OAuth1.0a 协议，OAuth2.0 更加简单清晰，同时加密方式依赖https的可信传输而非 OAuth1.0a 的 Token 签名加密，同时提供了多个途径如授权码、刷新令牌等去获取访问 Token 令牌，适用场景更广。因此国内的第三方登录服务商也大多使用或参考了 OAuth2.0 协议的实现方式。

例如某知名社交 APP 的授权流程：

由上图可以看到一次完整的第三方登录流程涉及到了三方：用户，第三方登录服务提供者(如微博、微信、QQ等)，APP 应用自身。任何一方如果出现了安全薄弱点，则会击溃整个安全认证体系。

实际上 OAuth2.0 协议在设计时已经考虑到了可能存在的攻击面，并且也提供了相应的应对建议

• https://tools.ietf.org/html/rfc6819

第三方服务商在提供第三方登录服务时，也大多考虑到了这些存在的风险，因此更多的攻击点在 APP 自身。

接下来本文介绍一种 APP常见的漏洞：Appsecret、Access_Token 泄露。

APP 用户信息泄露的根源之一

Appsecret、Access_Token 泄露    

开发者在类似微博应用开发平台、微信开放平台注册应用后，平台一般会给开发者颁发 Appid、Appsecret 这两个字段，这个是应用的唯一标示，使用这两个字段的目的主要是确保应用是开发者本人在使用。

同时这种第三方开放平台还会开放给开发者不同的 API 接口，可以进行一些授权的操作行为，如发微博、加关注、微信关注者管理、推送公共号消息等，这些都需要开发者在访问请求 API 时，带上 Appid、Appsecret 或者 Access_Token 字段。

△ 获取 Access_Token

△ 获取关注用户信息

所以如果这两个字段任意一个泄漏、那么就会泄漏很多用户相关信息、并且可进行敏感操作。 

既然 Appid、Appsecret 如此重要，想必开发者们应该相当重视其保密性吧，实则不然，由于用户登录授权时需要使用到 Appid、Appsecret，很多第三方 APP 开发者为了使用方便，会将这两个字段写死在代码里面，在用户授权之后，则在 APP 本地将 Code、Secret 等字段拼接并请求第三方登录后台。

这种常见的错误实现方式如下图：

错误实例代码

private String url = "https://api.weixin.qq.com/sns/oauth2/access_token?";

private WxEntity wx;

this.code = ((SendAuth.Resp)paramBaseResp).code;

this.wx=((UserInfoService)ServiceFactory.getService("userInfoService")).getToken(this.url,"wxbd8xxxxxxxxxxx","8bfed4e81be113exxxxxxxxxxxxxxxx",this.code, "authorization_code");

这种实现方式将 Appid、Appsecret 写死在 APP 的代码之中，如果应用被黑客给反编译破解之后 (反破解可用乐固加固)，那么 Appid、Appsecret 就会被黑客窃取。从而可以伪装应用进行敏感操作、给第三方开发者带来经济和口碑上的损失。

同时，如 APP将用户授权后 Access_Token 进行本地存储的话，也会被黑客窃取。这些都是不安全的方式。

乐固对某社交 APP 漏洞扫描实况

针对 APP 开发者的这种不安全的实现方式，乐固漏洞扫描提供了自动化扫描的能力，能够检查出是否有不安全的实现方式，是否采取了不安全的存储等漏洞风险、能够智能有效地挖掘出应用的安全漏洞。

PS：在授权情况下进行的扫描

△ 扫描实况

△ 报告示例

建议修复方式

建议Appsecret、用户数据（如 Access_Token）放在 APP 云端服务器，由云端中转接口调用请求。

可以通过以下这种方式进行实现：

△ 建议修复的实现方式

Hey guys，本期授权登录里的这些漏洞风险你了解了吗？在移动 APP 安全方面，网民与开发者们还将遇到怎样的问题？看到这里的你又遇到过什么问题？欢迎留言给安小妹，我们一起与腾讯移动安全专家探讨。

乐固系列第二次与大家见面，对我们「移动 APP 安全揭秘第二期」满意度如何？下期期待什么样的内容？安小妹耐心听你说。