高质量解读《互联网企业安全高级指南》三部曲（技术篇）——移动应用安全

前言：
高效读书，一张逻辑图读懂、读薄书中重点。
注：下面文字只是对逻辑思维图的”翻译“，节省时间，只看图即可。

移动应用安全逻辑思维图

 1.    说明
1.1.    互联网公司的安全体系基本上以运维安全，应用安全，业务安全三管齐下。而移动应用安全则在应用安全中占据半壁江山，尤其对于移动端产品为主的公司而言，SDL的主要实践对象就是移动应用
2.    背景
2.1.    随着智能手机和其他移动设备的爆发式普及，移动应用已成为互联网公司业务重要的业务方向。本章中会以移动两大平台之一的安卓为主线，介绍移动应用所面临的安全风险和解决方案
3.    业务架构分析
3.1.    移动应用很少会单独存在，多数情况下会作为互联网业务流程中的承载平台出现。如果业务同时存在传统Web页面服务模式，两者从逻辑上处于并行的关系，只是不同的表现  
形式
3.2.    作为一种运行在用户控制设备上的应用，业务服务端应该假设客户端提交的信息存在各种可能，在设计时需要关注哪些逻辑适合放在移动端，哪些逻辑需要保留在服务端
3.3.    涉及业务核心数据的行为，例如游戏中的物品掉落，支付行为的判断，账号信息的更改等都需要在业务服务端进行判断，而非客户端
4.    移动操作系统安全简介
4.1.    图10-1是安卓系统的架构和安全相关的介绍可以参看https://source.android.com/security/index.html

4.1.1.    硬件设备：安卓可运行在范围广泛的硬件上，并且支持某些硬件特有的安全功能， 例如 ARM v6 的 eXecute-Never 功能
4.1.2.    安卓操作系统：底层为Linux内核，所有设备资源都通过该层提供，包括相机、GPS
数据、蓝牙、电话、网络等服务
4.1.3.    安卓应用：通常使用Java开发，运行在Dalvik/ART虚拟机中，除此之外还包括一些二进制的组件。应用中不论是虚拟机还是二进制的部分都在相同的安全域，也就是该应用的沙盒中
4.2.    现代移动操作系统和早期操作系统相比有一定的优势，以Windows为例，在不断更新的过程中，会被过去的理念和代码实现所拖累。而安卓和iOS作为之后设计开发的操作系 统，在设计上加入了一些新的理念
5.    签名管理
5.1.    为了确定应用的来源，无论安卓还是iOS都会对应用的签名进行检查，确保用户安装的应用来源可控
5.2.    对于应用开发方，应该保护好本公司用于应用签名的私钥，推荐的解决方案是建立签名服务器
5.3.    在同一家公司内的应用推荐使用相同的签名密钥， 避免不同的应用使用不同的签名，这样不仅便于之后的发布和管理，在技术也便于之后可能存在的应用间通信需求
6.    应用沙盒及权限
6.1.    如之前所说，安卓和iOS作为之后设计开发的操作系统，在设计上加入了一些新的理念，其中重要的一点是通过沙盒(Sandbox)对各应用间的权限隔离，并在限定应用行为边界后，通过按需申请应用权限的方式规范各应用的行为，这样就将单个应用面临的风险和其他应用以及操作系统相隔离
6.2.    在安卓系统上，在接触任何系统资源前，应用都要通过权限检查，如图10-2所示

6.3.    如何实现沙盒
6.3.1.    安卓和iOS内核都源自*nix类系统内核，对应用沙盒的技术实现都是基于操作系统提供的用户机制。每个在系统上安装的应用，如果没有特殊设 定(SYSTEM或者安卓中SHARED-UID模式)，都会有系统分配给应用一个独特的用户ID (UID),单凭该UID,应用无法使用任何应用外的设备资源。只有当应用在安装时预先申请了某些系统权限后，才会被准许进行权限对应的操作
7.    应用安全风险分析
7.1.    在应用和业务逻辑已经剥离的情况下，仍然可能存在严重的安全风险（接口和数据来源）
7.2.    风险列表示例
7.2.1.    应用间通信（IPC）:提供接口的组件权限，信息泄露，本地的数据加密和文件权限等，以安卓为例，IPC 接 口包括 Content Provider, Broadcast Receiver, Activity, Service 等形式
7.2.2.    远程数据：开放端口接收数据，接收的各类型文件，应用的自动升级，数据传输明文等
7.2.3.    两类目标：用户：内容伪造，导致不能正确判断，程序：代码实现上的漏洞，代码执行, 权限窃取和绕过。从严重程度来看，首先需要注意远程来源数据
8.    安全应对
8.1.    对于三方的选择，建议选取保持更新的开源项目，查看项目升级日志中修补过的安全列表，确认应用中将要使用的版本是否已经修补已知安全问题，并订阅此项目的版本更新邮件，能在之后发布安全更新时第一时间评估影响
8.2.    具体到自身代码的引入的问题，需要符合最小化原则
8.2.1.    对只需要应用自身使用到的组件，不提供给其他应用
8.2.2.    对于不需要开放的端口，限定监听在特定的IP
8.2.3.    对于本地保存的数据库或文件等，严格的限定读写权限等
8.2.4.    在需要时提供完善的认证和加密机制
9.    安全评估
9.1.    代码审计
9.1.1.    iOS开发Xcode环境可使用整合的Clang Static Analyzer,而安卓Java代码可以 使用FindBugs来完成代码安全审计。具体审计范围和使用可参考之后第II章“代码审计”
9.2.    应用加固
9.2.1.    目前有一些在线的应用安全加固服务。用户可上传需要加固的应用，服务器接收应用后会从安全，逆向和调试难度等方面对应用进行评估，并按照用户需要提供在这些方面完 成更改后的版本供下载
10.    关于移动认证
10.1.    为了方便用户登录认证，通常移动应用通过保存登录信息或者加上简单的本地认证方式（如手势密码或者数字PIN码）来使用户免于输入完整的流程
10.2.    以支付宝为例，限定数额以下的付款甚至不需要认证
10.2.1.    这背后有很多需要背景数据收集，从第一次正常登录时设备本身的信息，包括用户日常操作行为收集的大数据等。在发现异常时，就会触发完整的认证过程了
10.2.2.    当然在攻击者完全控制手机的情况，如果所有认证信息的要素都可以通过手机获取到，例如保存的认证信息，动态认证短信等，更多能够做到的也只有提高攻击的成本，而不能完全避免认证信息的盗用