合规安全大考核：移动应用安全策略全盘点

飞奔的炮台

据统计，每年至少新增 150 万种移动恶意软件，至少造成超过 1600 万件的移动恶意软件攻击事件。
而 Android 因其开放性的生态环境，安全问题更是相当严峻。在应用市场上，很多 Android App 都存在潜在的安全风险，一旦被利用，会给用户和开发者带来很大影响。
同时，伴随《网络安全法》以及《个人信息保护法》等相关法律法规的出台和落地，移动应用开发者们也需要协同政府部门，共同营造安全的移动应用环境，促进网络安全的规范化、安全化、健康化发展。
为帮助移动开发者有效应对应安全要求，mPaaS 内很多模块都采用了安全策略：

  

• 移动应用安全加固
    
  
• 隐私合规检测
    
  
• RPC 的加签加密
    
  
• 离线包的签名校验
    
  
• 移动同步的tcp+ssl机制
    
  
• 热修复的加密配置
  
  

……
本文将为大家介绍上述常见 mPaaS 关于安全设计的几种模块，便于后续更好的使用。
隐私合规检测
随着政策法规及监管标准不断细化深化，监管查处力度的不断加大，App 开发方需要面临的政策风险也在逐步增加。
mPaaS 隐私合规检测服务，依据国家相关法律法规及行业规范，对移动 App 隐私安全、个人数据收集和使用进行合规分析。
从个人信息收集、权限使用场景、隐私政策等多个维度帮助企业及 App 开发者识别安全风险，提供对应的专家整改建议，助力客户规避监管处罚及通过审核上架。

移动安全加固
结合着阿里内部移动应用安全加固能力的升级，我们现已在 mPaaS 中对外输出移动应用安全加固能力。
针对市面上移动应用普遍存在的破解、篡改、盗版、钓鱼欺诈、内存调试、数据窃取等各类安全风险，mPaaS 移动安全加固为 App 提供稳定、简单、有效的安全防护，提升 App 整体安全水平，力保 App 不被破解和攻击。
在应对 Android 常见的攻击手段，比如 反编译、二次打包、动态调试等的同时，我们也注重性能和兼容性。

  

• 加固能力经历了淘宝、菜鸟等上亿业务的实践，在安全性上有保障；
    
  
• 在兼容性上，我们支持 4.2 到 Android Q 的 版本；
    
  
• 能够支持 arm、x86、x64 的系统架构，在复杂的环境下稳定运行，奔溃率低；
    
  
• 另外，通过对于类的混淆保护，增加攻击者逆向 App 的难度，让攻击无从下手。
  
  

RPC
作为 mPaaS 最重要的组件之一，RPC 提供了客户端和服务端的安全通信通道，其中涉及安全的主要包括加签和加密。其中加签解决的是防止客户端被伪造，加密解决的是防止请求数据被泄漏。
1 加签

整体流程：

  

• 在 mPaaS 后台初始化应用的时候，会为每一个 App 创建一个唯一的appSecret；
    
  
• 客户端通过appid、WorkspaceID、appSecret等信息，生成无线保镖图片。通过无线保镖模块的加密，保证了存放在客户端的 appSecret 的安全性；
    
  
• 客户端请求的时候，从无线保镖获取 appSecret，同时添加 OperationType、time、requestData 等因子做 MD5 计算，添加到 header 发到 MGS 网关；
    
  
• MGS 收到后按照同样的方法再计算一次 MD5，如果一致，则通过校验。
  
  

优势：通过无线保镖机制，保证了内置在客户端内的 appSecret 的安全性。
2 加密

整体流程：

  

• 通过 openssl 生成非对称秘钥，客户端保存公钥，服务端报错私钥；
    
  
• 客户端每次请求 RPC 都会生成一个新的对称秘钥，通过第一步生成的非对称秘钥进行加密，生成 SecKey；
    
  
• 客户端使用对称密钥同时对原始数据进行加密，得到加密的数据 SecData；
    
  
• 移动网关通过保存的私钥对 SecKey 进行解密得到对称密钥；
    
  
• 通过上一步得到的对称秘钥，对加密数据SecData进行解密，得到原始数据。
  
  

优势：RPC 的加密采用了混合加密的模式，使用了非对称加密和对称加密的组合。如果单纯使用对称秘钥，虽然性能较好，但是保证不了足够的安全性。如果单独使用非对称加密，虽然保证了安全性，但是会导致性能变差，不适合RPC这种大量通信的场景。
所以RPC采取的这种混合加密模式，很好的结合了两者的优点。
3 防抓包
在客户端端为了防止数据被抓包软件抓到，客户端进行了防止抓包的设置，通过设置网络库禁止代理的方式，解决了被抓包的风险。代码如下：

离线包
作为业务使用很多的离线模块，为了保证下发到本地的离线包模块没有被篡改，离线包提供了签名校验机制。
整体流程：

  

• 提前通过 openssl 生成公钥和私钥，公钥内置在客户端内，私钥存储到服务端；
    
  
• 离线包打包的时候，服务端对当前离线包的文件做 MD5 计算，然后将计算后的值通过非对称秘钥进行加密生成加密后的签名数据，随离线包下发到客户端；
    
  
• 客户端每次打开离线包的时候，通过客户端内的公钥获取下发的 MD5 和本地的离线包文件做 MD5 对比，如果一致，则校验通过，如果不一致，则删除离线包，直接访问 fallback 资源。
  
  

优势：

  

• 由于是每次打开离线包都做校验，保证了离线包的来源正确和不被篡改;
    
  
• 校验失败后直接降级到fallback地址，减少对客户使用的影响
  
  

MDS 实时发布
MDS 实时发布服务提供了 apk 的发布功能，同时为了保证下载的 apk 文件不被篡改，提供了基于 MD5 的完整性校验。
在上传 apk 的时候，会基于当前的 apk 生成 MD5 下发，本地安装的时候本地下载文件的 MD5 和会和服务端下发的 MD5 做匹配，如果匹配成功才会继续安装。
服务端下发的 MD5 字段如下图所示:

MSS 移动同步
移动同步服务 Sync 是基于 TCP 进行通信的，为了保证安全，Sync 可以配置为 TCP+SSL 模式进行通信。
当指定 Sync 的端口号为 433 端口后，客户端就会开始基于 TCP+SSL 实现长连接，长连接请求到服务端后，需要通过 F5 或者其他类似负载装置完成 SSL 卸载，最后到 MSS 实现长连接。
整体流程如下图所示：

结语
随着移动应用的迅猛发展，用户对于移动应用涉及到的隐私问题、安全问题日益关注。
移动应用涵盖用户大量个人数据，一旦发生泄漏可能对个人、社会造成重大影响，同时对移动应用产业长远的发展来说也是毁灭性打击。
移动应用开发者，也应注意开发过程中的规范性、安全性，敬畏安全问题，防范合规风险。
本文作者：阿里云 mPaaS TAM 团队（荣阳）
END