ANDROID应用安全防御
- - 移动开发 - ITeye博客Android应用的安全隐患包括三个方面：代码安全、数据安全和组件安全. 代码安全主要是指Android apk有被篡改、盗版等风险，产生代码安全的主要原因是apk很容易被反编译、重打包. 我们可以采用以下方法对apk进行保护：. 代码混淆可以在一定程度上增加apk逆向分析的难度. Android SDK从2.3开始就加入了ProGuard代码混淆功能，开发者只需进行简单的配置就可以实现对代码的混淆.
ANDROID应用安全防御
标签：
android
应用
安全
| 发表时间：2015-04-02 10:06 | 作者：yangsongjing
出处：http://www.iteye.com
Android应用的安全隐患包括三个方面：代码安全、数据安全和组件安全。
1. 代码安全
代码安全主要是指Android apk有被篡改、盗版等风险，产生代码安全的主要原因是apk很容易被反编译、重打包。我们可以采用以下方法对apk进行保护：
1.1 代码混淆
代码混淆可以在一定程度上增加apk逆向分析的难度。Android SDK从2.3开始就加入了ProGuard代码混淆功能，开发者只需进行简单的配置就可以实现对代码的混淆。
1.2 Apk签名校验
每一个软件在发布时都需要开发人员对其进行签名，而签名使用的密钥文件时开发人员所独有的，破解者通常不可能拥有相同的密钥文件，因此可以使用签名校验的方法保护apk。Android SDK中PackageManager类的getPackageInfo()方法就可以进行软件签名检测。
1.3 Dex文件校验
重编译apk其实就是重编译了classes.dex文件，重编译后，生成的classes.dex文件的hash值就改变了，因此我们可以通过检测安装后classes.dex文件的hash值来判断apk是否被重打包过。
（1）读取应用安装目录下/data/app/xxx.apk中的classes.dex文件并计算其哈希值，将该值与软件发布时的classes.dex哈希值做比较来判断客户端是否被篡改。
（2）读取应用安装目录下/data/app/xxx.apk中的META-INF目录下的MANIFEST.MF文件，该文件详细记录了apk包中所有文件的哈希值，因此可以读取该文件获取到classes.dex文件对应的哈希值，将该值与软件发布时的classes.dex哈希值做比较就可以判断客户端是否被篡改。
为了防止被破解，软件发布时的classes.dex哈希值应该存放在服务器端。
另外由于逆向c/c++代码要比逆向Java代码困难很多，所以关键代码部位应该使用Native C/C++来编写。
1.4 逆向工具对抗
对apk进行重打包常用的工具是apktool，apktool对于后缀为PNG的文件，会按照PNG格式进行处理，如果我们将一个非PNG格式文件的文件后缀改为PNG，再使用apktool重打包则会报错。
以上是使用比较多的几种保护方法，单独使用其中一种效果不大，应该综合运用。
1.5 调试器检测
为了防止apk被动态调试，可以检测是否有调试器连接。在Application类中提供了isDebuggerConnected()方法用于检测是否有调试器连接，如果发现有调试器连接，可以直接退出程序。
1.6 加壳保护
使用加壳程序防止apk逆向是一种非常有效的方式，也是一个趋势。Jack_Jia在《Android APK加壳技术方案》一文中详细阐述了Android apk加壳原理以及几种加壳方案的具体实现。我们可以利用这几种方案对apk进行加壳。
不过这种加壳方式是在Java层实现的，被反编译的风险仍然很大。为了克服这个缺点，今后可以研究采用如下思路来进行保护：
将核心业务逻辑代码放入加密的.jar或者.apk文件中，在需要调用时使用Native C/C++代码进行解密，同时完成对解密后文件的完整性校验。如果需要更加安全的保护方法，可以考虑对so文件（Native C/C++代码编译得到的文件）进行加壳。Android so加壳主要需要解决两个问题：
（1）对ELF文件加壳；
（2）对Android SO的加载、调用机制做特殊处理。
这将是以后Android应用安全研究的一个方向。
2. 数据安全
2.1 存储安全问题
关于数据存储可能出现的问题包括如下几点：
（1）明文存储敏感数据，导致直接被攻击者复制或篡改。
将隐私数据明文保存在外部存储
将系统数据明文保存在外部存储
将软件运行时依赖的数据保存在外部存储
将软件安装包或者二进制代码保存在外部存储
全局可读写的内部文件存储
（2）不恰当存储登陆凭证，导致攻击者利用此数据窃取网络账户隐私数据。
解决方案：
对这些数据进行加密，密码保存在内部存储，由系统托管或者由用户使用时输入。
对应用配置文件，较安全的方法是保存到内部存储；如果必须存储到SD卡，则应该在每次使用前检验它是否被篡改，与预先保存在内部的文件哈希值进行比较。
应用如果需要安装或加载位于SD卡的任何文件，应该先对其完整性做验证，判断其与实现保存在内部存储中的（或从服务器下载来的）哈希值是否一致。
如果要跨应用进行数据共享，有种较好的方法是实现一个Content Provider 组件，提供数据的读写接口并为读写操作分别设置一个自定义的权限。
对于登录凭证的存储，使用基于凭据而不是密码的协议满足这种资源持久访问的需求，例如OAuth。
2.2 传输安全问题
• 不使用加密传输
• 使用加密传输但忽略证书验证环节
如开发者在代码中不检查服务器证书的有效性，或选择接受所有的证书时，这种做法可能会导致中间人攻击。
我们在对敏感数据进行传输时应该采用基于SSL/TLS的HTTPS进行传输。由于移动软件大多只和固定的服务器通信，我们可以采用“证书锁定”（certificate pinning）方式在代码更精确地直接验证服务器是否拥有某张特定的证书。
3. 组件安全
android应用内部的Activity、Service、Broadcast Receiver等组件是通过Intent通信的，组件间需要通信就需要在Androidmanifest.xml文件中配置，不恰当的组件配置则会带来风险。
可能产生的风险：
（1）恶意调用
（2）恶意接受数据
（3）仿冒应用，例如（恶意钓鱼，启动登录界面）
（4）恶意发送广播、启动应用服务。
（5）调用组件，接受组件返回的数据
（6）拦截有序广播
解决办法：
（1）最小化组件暴露
不参与跨应用调用的组件添加android:exported="false"属性，这个属性说明它是私有的，只有同一个应用程序的组件或带有相同用户ID的应用程序才能启动或绑定该服务。
（2）设置组件访问权限
对参与跨应用调用的组件或者公开的广播、服务设置权限。只有具有该权限的组件才能调用这个组件。
（3）暴露组件的代码检查
Android 提供各种API来在运行时检查、执行、授予和撤销权限。这些 API 是 android.content.Context 类的一部分，这个类提供有关应用程序环境的全局信息。
另外，Android应用也会存在很多传统web漏洞，比如SQL注入，xss漏洞等，代码级防止出现这些漏洞的方法与web应用防御方法相同。
ANDROID系统安全防御
1. 操作系统安全问题
Android root问题
系统漏洞，补丁更新不及时
认证机制问题
2. 系统安全解决方案
2.1 权限管理与隔离
对运行在Android系统上的应用程序进行权限的细粒度管理和隔离，防止越权行为的发生和滥用权限获取敏感数据。
可以采用MAC（Mandatory Access Control）强制访问控制模型实现。它是一个针对Linux的安全加强系统SELinux中使用的安全模型，即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限。Google在Android 4.4上正式推出了一套以SELinux为基础的系统安全机制SEAndroid。所以如果我们要定制一个Android系统，可以采用具有SEAndroid安全机制的Android 4.4版本。
2.2 内核与应用层漏洞防护
增加补丁更新功能，如果发现漏洞，及时提醒用户进行系统补丁更新。
2.3 恶意程序检测与防护
建立一套恶意代码防护模型，对运行在Android系统上的恶意程序进行检测，抵御恶意代码的入侵。
2.4 数据安全存储与传输：
对Android系统上的数据存储和数据传输进行加密保护，保证终端上数据能够安全地使用。
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
1. 代码安全
代码安全主要是指Android apk有被篡改、盗版等风险，产生代码安全的主要原因是apk很容易被反编译、重打包。我们可以采用以下方法对apk进行保护：
1.1 代码混淆
代码混淆可以在一定程度上增加apk逆向分析的难度。Android SDK从2.3开始就加入了ProGuard代码混淆功能，开发者只需进行简单的配置就可以实现对代码的混淆。
1.2 Apk签名校验
每一个软件在发布时都需要开发人员对其进行签名，而签名使用的密钥文件时开发人员所独有的，破解者通常不可能拥有相同的密钥文件，因此可以使用签名校验的方法保护apk。Android SDK中PackageManager类的getPackageInfo()方法就可以进行软件签名检测。
1.3 Dex文件校验
重编译apk其实就是重编译了classes.dex文件，重编译后，生成的classes.dex文件的hash值就改变了，因此我们可以通过检测安装后classes.dex文件的hash值来判断apk是否被重打包过。
（1）读取应用安装目录下/data/app/xxx.apk中的classes.dex文件并计算其哈希值，将该值与软件发布时的classes.dex哈希值做比较来判断客户端是否被篡改。
（2）读取应用安装目录下/data/app/xxx.apk中的META-INF目录下的MANIFEST.MF文件，该文件详细记录了apk包中所有文件的哈希值，因此可以读取该文件获取到classes.dex文件对应的哈希值，将该值与软件发布时的classes.dex哈希值做比较就可以判断客户端是否被篡改。
为了防止被破解，软件发布时的classes.dex哈希值应该存放在服务器端。
另外由于逆向c/c++代码要比逆向Java代码困难很多，所以关键代码部位应该使用Native C/C++来编写。
1.4 逆向工具对抗
对apk进行重打包常用的工具是apktool，apktool对于后缀为PNG的文件，会按照PNG格式进行处理，如果我们将一个非PNG格式文件的文件后缀改为PNG，再使用apktool重打包则会报错。
以上是使用比较多的几种保护方法，单独使用其中一种效果不大，应该综合运用。
1.5 调试器检测
为了防止apk被动态调试，可以检测是否有调试器连接。在Application类中提供了isDebuggerConnected()方法用于检测是否有调试器连接，如果发现有调试器连接，可以直接退出程序。
1.6 加壳保护
使用加壳程序防止apk逆向是一种非常有效的方式，也是一个趋势。Jack_Jia在《Android APK加壳技术方案》一文中详细阐述了Android apk加壳原理以及几种加壳方案的具体实现。我们可以利用这几种方案对apk进行加壳。
不过这种加壳方式是在Java层实现的，被反编译的风险仍然很大。为了克服这个缺点，今后可以研究采用如下思路来进行保护：
将核心业务逻辑代码放入加密的.jar或者.apk文件中，在需要调用时使用Native C/C++代码进行解密，同时完成对解密后文件的完整性校验。如果需要更加安全的保护方法，可以考虑对so文件（Native C/C++代码编译得到的文件）进行加壳。Android so加壳主要需要解决两个问题：
（1）对ELF文件加壳；
（2）对Android SO的加载、调用机制做特殊处理。
这将是以后Android应用安全研究的一个方向。
2. 数据安全
2.1 存储安全问题
关于数据存储可能出现的问题包括如下几点：
（1）明文存储敏感数据，导致直接被攻击者复制或篡改。
将隐私数据明文保存在外部存储
将系统数据明文保存在外部存储
将软件运行时依赖的数据保存在外部存储
将软件安装包或者二进制代码保存在外部存储
全局可读写的内部文件存储
（2）不恰当存储登陆凭证，导致攻击者利用此数据窃取网络账户隐私数据。
解决方案：
对这些数据进行加密，密码保存在内部存储，由系统托管或者由用户使用时输入。
对应用配置文件，较安全的方法是保存到内部存储；如果必须存储到SD卡，则应该在每次使用前检验它是否被篡改，与预先保存在内部的文件哈希值进行比较。
应用如果需要安装或加载位于SD卡的任何文件，应该先对其完整性做验证，判断其与实现保存在内部存储中的（或从服务器下载来的）哈希值是否一致。
如果要跨应用进行数据共享，有种较好的方法是实现一个Content Provider 组件，提供数据的读写接口并为读写操作分别设置一个自定义的权限。
对于登录凭证的存储，使用基于凭据而不是密码的协议满足这种资源持久访问的需求，例如OAuth。
2.2 传输安全问题
• 不使用加密传输
• 使用加密传输但忽略证书验证环节
如开发者在代码中不检查服务器证书的有效性，或选择接受所有的证书时，这种做法可能会导致中间人攻击。
我们在对敏感数据进行传输时应该采用基于SSL/TLS的HTTPS进行传输。由于移动软件大多只和固定的服务器通信，我们可以采用“证书锁定”（certificate pinning）方式在代码更精确地直接验证服务器是否拥有某张特定的证书。
3. 组件安全
android应用内部的Activity、Service、Broadcast Receiver等组件是通过Intent通信的，组件间需要通信就需要在Androidmanifest.xml文件中配置，不恰当的组件配置则会带来风险。
可能产生的风险：
（1）恶意调用
（2）恶意接受数据
（3）仿冒应用，例如（恶意钓鱼，启动登录界面）
（4）恶意发送广播、启动应用服务。
（5）调用组件，接受组件返回的数据
（6）拦截有序广播
解决办法：
（1）最小化组件暴露
不参与跨应用调用的组件添加android:exported="false"属性，这个属性说明它是私有的，只有同一个应用程序的组件或带有相同用户ID的应用程序才能启动或绑定该服务。
（2）设置组件访问权限
对参与跨应用调用的组件或者公开的广播、服务设置权限。只有具有该权限的组件才能调用这个组件。
（3）暴露组件的代码检查
Android 提供各种API来在运行时检查、执行、授予和撤销权限。这些 API 是 android.content.Context 类的一部分，这个类提供有关应用程序环境的全局信息。
另外，Android应用也会存在很多传统web漏洞，比如SQL注入，xss漏洞等，代码级防止出现这些漏洞的方法与web应用防御方法相同。
ANDROID系统安全防御
1. 操作系统安全问题
Android root问题
系统漏洞，补丁更新不及时
认证机制问题
2. 系统安全解决方案
2.1 权限管理与隔离
对运行在Android系统上的应用程序进行权限的细粒度管理和隔离，防止越权行为的发生和滥用权限获取敏感数据。
可以采用MAC（Mandatory Access Control）强制访问控制模型实现。它是一个针对Linux的安全加强系统SELinux中使用的安全模型，即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限。Google在Android 4.4上正式推出了一套以SELinux为基础的系统安全机制SEAndroid。所以如果我们要定制一个Android系统，可以采用具有SEAndroid安全机制的Android 4.4版本。
2.2 内核与应用层漏洞防护
增加补丁更新功能，如果发现漏洞，及时提醒用户进行系统补丁更新。
2.3 恶意程序检测与防护
建立一套恶意代码防护模型，对运行在Android系统上的恶意程序进行检测，抵御恶意代码的入侵。
2.4 数据安全存储与传输：
对Android系统上的数据存储和数据传输进行加密保护，保证终端上数据能够安全地使用。
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
相关 [android 应用 安全] 推荐：
Android 应用安全风险与防范
- - DiyCode - 致力于构建开发工程师高端交流分享社区社区Hello，大家好，我是Clock. 最近一段时间在做Android应用安全方面的功课，本文进行简单梳理方便以后Review，有错误和遗漏之处还请大家指出. Android开发除了部分功能采用C/C++编码外，其余主要都是采用Java进行编码开发功能. Java应用非常容易被反编译，Android自然也不例外.
Android应用安全之脆弱的加密 - bamb00
- - 博客园_首页程序员希望通过加密来提升程序的安全性性，但却缺乏专业的密码学背景知识，使得应用对数据的保护非常薄弱. 本文将介绍可能出现在Android应用中的一些脆弱的加密方式，以及对应的攻击方法. Android应用中造成弱加密的原因多种多样，OWASP Mobile Top 10 给出了几个原因： . 使用了强健的加密算法，但加密的实现存在漏洞.
两款免费的Android应用代码安全检测工具
- - FreeBuf.COM | 关注黑客与极客FreeBuf前不久刚刚 报道过，美图秀秀、gReader、福昕PDF阅读器等14款Android应用易遭中间人攻击. 今天，央视《 新闻直播间》也用“黄金三分钟”介绍了安卓手机上存在的名为“寄生兽”的通用型安全漏洞，影响规模达到数以千万级的用户，市面上安卓90％APP都中招. 今年6月Android智能手机在美国的市场份额上升2.8%，达到64.9%.
Android应用安全开发之浅谈网页打开APP
- - WooYun知识库Author:伊樵，呆狐，舟海@阿里移动安全. 0x00 网页打开APP简介. Android有一个特性，可以通过点击网页内的某个链接打开APP，或者在其他APP中通过点击某个链接打开另外一个APP（AppLink），一些用户量比较大的APP，已经通过发布其AppLink SDK，开发者需要申请相应的资格，配置相关内容才能使用.
从零开始学Android应用安全测试（Part1）
- - FreeBuf.COM | 关注黑客与极客在本系列文章中，利用InsecureBankv2这款含有漏洞的安卓应用，我们可以了解到有关安卓应用安全的种种概念. 我们将从一个新手的角度看待每一个问题. 所以，我建议新手朋友可以关注下本系列文章. 由于教程是从零开始，前面的东西不免会比较基础，老鸟请先飞过吧. 在对安卓应用测试之前，我们需要搭建一个合适的移动渗透平台.
腾讯应用中心Android客户端上线 设安全认证
- Tony - cnBeta.COMAndroid腾讯应用中心客户端昨日全新上线，其前身是“QQ手机软件管理”. 腾讯应用中心Android客户端全新的UI和架构，显示出腾讯应用中心的社区化和开放平台理念，同时腾讯应用中心每款应用都经专业的QQ手机管家认证，用户下载更安心.
92%的主流Android应用都存在安全或隐私风险
- - IT经理网云移动风险管理公司 MetaIntell近日对包括亚马逊、CNET以及谷歌官方应用商店Google Play中，人们最常下载的前500名应用进行测试后发现，92%的Android应用都采用了不安全的通讯协议，60%的应用与黑名单列表中的网站通讯，20%的应用在用户不知情或未经用户授权的情况下加载远程或者本地应用.
GetEd2k （Android应用）
- 某牢 - eMule Fans 电骡爱好者GetEd2k是一个Android应用程序，作者是anacletus. 此应用可以帮助你把网页中的电驴(eDonkey) 链接添加到你个人电脑的电驴客户端里，不过前提是你的客户端开启了用于远程控制的Web interface（Web服务器，网页接口，Web界面），当然，eMule（电骡）， MLDonkey 和 aMule 都支持该功能，所以这三种主流电驴客户端的用户都可以使用GetEd2k.
Android操作系统安全
- - CSDN博客推荐文章 Android在迅猛发展的同时，其安全问题一直没有引起足够的重视，但在2010年6月研究人员发布Android平台的KernelRootkit以来，Android平台的安全问题引来了越来越多的关注，而同时，Android平台的恶意软件也开始流行起来. 根据以上的Android系统架构分析，可以发现在三个层面可能存在恶意软件.