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

受开发者欢迎的第三方登录是什么？
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 安全揭秘第二期」满意度如何？下期期待什么样的内容？我们耐心听你说。