互联网公司的安全体系基本上以运维安全，应用安全，业务安全三管齐下。而移动应用安全则在应用安全中占据半壁江山，尤其对于移动端产品为主的公司而言，SDL的主要实践对象就是移动应用。
随着智能手机和其他移动设备的爆发式普及，移动应用已成为互联网公司业务重要的业务方向。本文以移动两大平台之一的安卓为主线，介绍移动应用所面临的安全风险和解决方案。其中包含评估方法以及应对的思路，这些思路可以相应的借鉴于其他平台上。定义客户端应用安全的范围是什么，风险有哪些，攻击的来源，移动操作系统所提供的工具。在了解这些基本的判断之后，当一些新的技术出现，我们仍然可以用已有的标准去应对。
1、业务架构分析
移动应用很少会单独存在，多数情况下会作为互联网业务流程中的承载平台出现。如果业务同时存在传统Web页面服务模式，两者从逻辑上处于并行的关系，只是不同的表现形式。作为一种运行在用户控制设备上的应用，业务服务端应该假设客户端提交的信息存在各种可能，在设计时需要关注哪些逻辑适合放在移动端，哪些逻辑需要保留在服务端。涉及业务核心数据的行为，例如游戏中的物品掉落，支付行为的判断，账号信息的更改等都需要在业务服务端进行判断，而非客户端。这些分割需要从设计阶段对移动客户端能做哪些行为进行限定。
从整体业务角度来看，业务逻辑为皮，移动应用端的展示为毛。如何避免移动客户端做不应承担的判断，如何将应用安全和业务服务端逻辑进行划定是首先需要明确的。
2、移动操作系统安全简介
图1是安卓系统的架构。
图1 Android体系架构
硬件设备：安卓可运行在范围广泛的硬件上，并且支持某些硬件特有的安全功能，例如ARM v6的eXecute-Never功能。
安卓操作系统：底层为Linux内核，所有设备资源都通过该层提供，包括相机，GPS数据、蓝牙、电话、网络等服务。
安卓应用：通常使用Java开发，运行在Dalvik/ART虚拟机中，除此之外还包括一些二进制的组件。应用中不论是虚拟机还是二进制的部分都在相同的安全域，也就是该应用的沙盒中。
现代移动操作系统和早期操作系统相比有一定的优势，以Windows为例，在不断更新的过程中，会被过去的理念和代码实现所拖累。而安卓和iOS作为之后设计开发的操作系统，在设计上加入了一些新的理念。此外现代操作系统如安卓中包含了大量的漏洞利用缓解技术，例如ASLR，SELinux，FORTIFY_SOURCE编译选项等技术。这些技术能进一步提高利用漏洞的难度，降低漏洞利用成功率。
由于这些措施的运用，在未越狱或root的设备上，更多的需要考虑应用自身遇到的安全问题。应用需要信任并借用底层系统提供功能。
安卓在设计时已经考虑并集成了很多安全相关的功能和组件，一款普通的应用在设计和开发过程中都可能用到这些。
一款安全应用大体的结构内容包括：数据安全性，服务安全性，应用权限安全性，以及其他一些内容。
3、签名管理
为了确定应用的来源，无论安卓还是iOS都会对应用的签名进行检查，确保用户安装的应用来源可控。在来源检查上iOS环境下更加可控一些，造成这种情况的原因很多，但最重要的一点是对应用市场的控制力。对于应用开发方，应该保护好本公司用于应用签名的私钥，推荐的解决方案是建立签名服务器，开发者上传需要签名的应用，服务器完成签名后提供下载。签名服务可对申请应用签名的人员进行权限控制，并包含日志记录，保存上传应用副本等功能，这样做的好处是降低私钥泄露的风险。
另外一点和签名相关的注意事项是，在同一家公司内的应用推荐使用相同的签名密钥，避免不同的应用使用不同的签名，这样不仅便于之后的发布和管理，在技术上也便于之后可能存在的应用间通信需求。无论iOS中的Keychain Access Group和安卓权限定义中要求的同签名来源（level=Signature）都要求应用被相同的密钥签名。
4、应用沙盒及权限
安卓和iOS作为之后设计开发的操作系统，在设计上加入了一些新的理念，其中重要的一点是通过沙盒（Sandbox）对各应用间的权限隔离，并在限定应用行为边界后，通过按需申请应用权限的方式规范各应用的行为。这样就将单个应用面临的风险和其他应用以及操作系统相隔离。
在安卓系统上，在接触任何系统资源前，应用都要通过权限检查，如图2所示。
图2 应用权限检查
是如何实现沙盒的？安卓和iOS内核都源自*nix类系统内核，对应用沙盒的技术实现都是基于操作系统提供的用户机制。每个在系统上安装的应用，如果没有特殊设定（SYSTEM或者安卓中SHARED-UID模式），都会有系统分配给应用一个独特的用户ID（UID），单凭该UID，应用无法使用任何应用外的设备资源。只有当应用在安装时预先申请了某些系统权限后，才会被准许进行权限对应的操作。
以安卓系统为例，申请系统权限需要按照如下格式在应用的AndroidManifest.xml文件中添加uses-permission的标签段。
<uses-permission android:name="string"android:maxSdkVersion="integer" />
其中android：name属性就是将要申请的权限名称。
此外，应用在申请系统提供的权限的同时，也可以声明创建新的自定义权限，并且和应用内提供的一些模块相关联。在下面的实例中，应用自定义了名为com.example.project.DEBIT_ACCT的权限，并且和com.example.project.FreneticActivity模块关联，之后如果其他应用需要调用该模块，就需要在自己的AndroidManifest.xml文件中声明使用com.example.project.DEBIT_ACCT：
<manifest . . . >
<permission android:name="com.example.project.DEBIT_ACCT" . . . />
<uses-permission android:name="com.example.project.DEBIT_ACCT" />
. . .
<application . . .>
<activity android:name="com.example.project.FreneticActivity"
android:permission="com.example.project.DEBIT_ACCT"
. . . >
. . .
</activity>
</application>
</manifest>
从上面的描述可以了解到，应用既可以作为权限的申请方，也可以提供自定义权限供其他应用使用，而这些自定义权限相配合的是背后各种组件。
5、应用安全风险分析
在应用和业务逻辑已经剥离的情况下，仍然可能存在严重的安全风险。首先需要意识到这些风险的根源是应用实现形态的多样性。在提倡模块化的今天，应用在实现过程中会分为数量众多的模块来实现，这些模块相互耦合，向模块外提供调用接口，或主动或被动的接收外部数据并影响内部逻辑。通过梳理这些接口和数据来源，可以获取到安全风险的来源列表。
这些调用接口的形式是多样的，应用既可以在同系统下的组件层面提供各种服务，也可能开放网络端口接受数据请求。此外客户端应用还更多的涉及文件内容的展示；各类型的视频，音频，文档，图片，皮肤等公有和自定义文件类型的展示，网页内容展示也给移动端应用带来了风险。在处理外部的数据过程中，会影响应用内部的逻辑。除了传统的数据来源，由于现代操作系统已经进行了应用间的权限隔离，如何避免同系统中其他应用窃取特定的权限也是需要关注的方面。下面是一些具体的风险列表：
应用间通信（IPC）：提供接口的组件权限，信息泄露，本地的数据加密和文件权限等，以安卓为例，IPC接口包括Content Provider，Broadcast Receiver，Activity，Service等形式。
远程数据：开放端口接收数据，接收的各类型文件，应用的自动升级，数据传输明文等两类目标：用户：内容伪造，导致不能正确判断；程序：代码实现上的漏洞，代码执行，权限窃取和绕过。从严重程度来看，首先需要注意远程来源数据。
6、安全应对
对于大多数应用来说，都会使用到自身代码之外的三方逻辑，这些逻辑可能存在于调用库中或作为独立组件被使用，这些逻辑可能引入安全问题。对于三方的选择，建议选取保持更新的开源项目，查看项目升级日志中修补过的安全列表，确认应用中将要使用的版本是否已经修补已知安全问题，并订阅此项目的版本更新邮件，能在之后发布安全更新时第一时间评估影响。
具体到自身代码的引入的问题，需要符合最小化原则。举例来说，对只需要应用自身使用到的组件，不提供给其他应用；对于不需要开放的端口，限定监听在特定的IP；对于本地保存的数据库或文件等，严格的限定读写权限等。除此之外，另外两方面就是在需要时提供完善的认证和加密机制。以WormHole系列漏洞为例，利用的风险来源是开放的端口，而这些端口在移动网络上的访问没有任何限制，并且在进行高危逻辑前没有做好认证，这就是最小化原则和认证机制的一个反例。
7、安全评估
（1）代码审计
iOS开发Xcode环境可使用整合的Clang Static Analyzer，而安卓Java代码可以使用FindBugs来完成代码安全审计。
（2）应用加固
目前有一些在线的应用安全加固服务。用户可上传需要加固的应用，服务器接收应用后会从安全，逆向和调试难度等方面对应用进行评估，并按照用户需要提供在这些方面完成更改后的版本供下载。
8、关于移动认证
为了方便用户登录认证，通常移动应用通过保存登录信息或者加上简单的本地认证方式（如手势密码或者数字PIN码）来使用户免于输入完整的流程。
以支付宝为例，限定数额以下的付款甚至不需要认证。这背后有很多需要背景数据收集，从第一次正常登录时设备本身的信息，包括用户日常操作行为收集的大数据等。在发现异常时，就会触发完整的认证过程了。当然在攻击者完全控制手机的情况，如果所有认证信息的要素都可以通过手机获取到，例如保存的认证信息，动态认证短信等，更多能够做到的也只有提高攻击的成本，而不能完全避免认证信息的盗用。
