企业网络安全之移动应用安全

互联网公司的安全体系基本上以运维安全,应用安全,业务安全三管齐下。而移动应用安全则在应用安全中占据半壁江山,尤其对于移动端产品为主的公司而言,SDL的主要实践对象就是移动应用。

互联网公司的安全体系基本上以运维安全,应用安全,业务安全三管齐下。而移动应用安全则在应用安全中占据半壁江山,尤其对于移动端产品为主的公司而言,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码)来使用户免于输入完整的流程。

以支付宝为例,限定数额以下的付款甚至不需要认证。这背后有很多需要背景数据收集,从第一次正常登录时设备本身的信息,包括用户日常操作行为收集的大数据等。在发现异常时,就会触发完整的认证过程了。当然在攻击者完全控制手机的情况,如果所有认证信息的要素都可以通过手机获取到,例如保存的认证信息,动态认证短信等,更多能够做到的也只有提高攻击的成本,而不能完全避免认证信息的盗用。

本文来自信息化观察者网,转载请注明出处。

 

注:本站文章除标明原创外,均来自网友投稿及分享,如有侵权请联系dongxizhiku@163.com删除。

         

发表评论