Android应⽤安全防御
Android应⽤安全防御
Android应⽤的安全隐患包括代码安全、数据安全、组件安全、WebView等⼏个⽅⾯。 1. 代码安全
代码安全主要是指Android apk容易被反编译，从⽽⾯临软件破解，内购破解，软件逻辑修改，插⼊恶意代码，替换⼴告商ID等风险。我们可以采⽤以下⽅法对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是否被重打包过。天下收藏2011
（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加壳原理以及⼏种加壳⽅案的具体实现。我们可以利⽤这⼏种⽅案对apk进⾏加壳。
不过这种加壳⽅式是在Java层实现的，被反编译的风险仍然很⼤。为了克服这个缺点，今后可以研究采⽤如下思路来进⾏保护：
将核⼼业务逻辑代码放⼊加密的.jar或者.apk⽂件中，在需要调⽤时使⽤Native C/C++代码进⾏解密，同时完成对解密后⽂件的完整性校验。如果需要更加安全的保护⽅法，可以考虑对so⽂件（Native C/C++代码编译得到的⽂件）进⾏加壳。Android so加壳主要需要解决两个问题：
半带滤波器
（1）对ELF⽂件加壳；
（2）对Android SO的加载、调⽤机制做特殊处理。
其实不管是Linux还是Windows，加壳的思路基本是⼀致的，简单点⽆⾮加密+拆解+混淆，复杂点如Stolen Code + VM等。所以确定好⼀个加壳⽅案之后，剩下的就是了解elf的⽂件结构和加载机制，然后⾃⼰写⼀套壳+loader。
Android上的loader是/system/bin/linker，跟linux上的ld有⼀些区别。但主要过程还是⼀致的：map + relocate + init。
Android so主要充当的⾓⾊是通过JNI与java交互，所以主要是作为⼀个库存在（也有⼀些so是可执⾏的），然后被Android runtime加载，并能被java层调⽤。所以对elf加完壳之后，还要对Android so做⼀些特殊处理：
1. Android so被System.LoadLibrary()加载之后，会将so的信息存储在⼀个全局链表⾥，所以要保证脱壳后的so能被这个链表访问到。
解决掉这两个问题之后，基本上⼀套Android SO加壳框架就成形了，后续就可以增加各种Anti tricks来完善壳的强度。
2. 数据安全
2.1 存储安全问题
关于数据存储可能出现的问题包括如下⼏点：外部存储（SD卡）上的⽂件没有权限管理，所有应⽤都可读可写。开发者把敏感信息明⽂存在 SD 卡上，或者动态加载的payload放在SD卡上。 （1）明⽂存储敏感数据，导致直接被攻击者复制或篡改。
将隐私数据、系统数据明⽂保存在外部存储
将软件运⾏时依赖的数据保存在外部存储
h9000将软件安装包或者⼆进制代码保存在外部存储
使⽤全局可读写（MODE_WORLD_READABLE，MODE_WORLD_WRITEABLE）的内部存储⽅式，或明⽂存储敏感信息（⽤户账号密码等）。
（2）不恰当存储登陆凭证，导致攻击者利⽤此数据窃取⽹络账户隐私数据。
解决⽅案：
对这些数据进⾏加密，密码保存在内部存储，由系统托管或者由⽤户使⽤时输⼊。
对应⽤配置⽂件，较安全的⽅法是保存到内部存储；如果必须存储到SD卡，则应该在每次使⽤前检验它是否被篡改，与预先保存在内部的⽂件哈希值进⾏⽐较。
应⽤如果需要安装或加载位于SD卡的任何⽂件，应该先对其完整性做验证，判断其与实现保存在内部存储中的（或从服务器下载来的）哈希值是否⼀致。
如果要跨应⽤进⾏数据共享，有种较好的⽅法是实现⼀个Content Provider 组件，提供数据的读写接⼝并为读写操作分别设置⼀个⾃定义的权限。
对于登录凭证的存储，使⽤基于凭据⽽不是密码的协议满⾜这种资源持久访问的需求，例如OAuth。
Android数据存储机制
存储⽅式描述数据保密性
Shared preferences ⽤来存储⼀些简单配置信息的⼀种机制，使⽤Map数据
结构来存储数据，以键值对的⽅式存储，采⽤了XML格
式将数据存储到设备中。例如保存登录⽤户的⽤户名和
密码。只能在创建它的应⽤中使⽤，其他应⽤⽆法使
⽤。不能指定存储⽂件的位置，创建的存储⽂件保存
在/data/data/<package name>/shares_prefs⽂件夹下。
⽀持的存储类型有：Boolean、Float、Integer、Long、
String等
可以设置四种模式：
MODE_PRIVATE（默认模式，⽂件只能让创建的应⽤程序访
问）、
MODE_WORLD_WRITEABLE、
MOED_WORLD_READABLE、
MODE_APPEND
内部存储在设备内存中存储数据。通常这些数据不允许被其它应
⽤甚⾄终端⽤户访问。即使重启设备，这些数据仍然存
擒敌拳在，不过当终端⽤户卸载程序后，这些数据就会被删
除。
可以设置三种模式：
MODE_PRIVATE（默认模式）、
MODE_WORLD_READABLE、
MODE_WORLD_WRITABLE
外部存储外部存储（SD卡）的数据是全局可读的。设备⽤户和其
它应⽤都能读取、修改、删除这些数据
数据默认是全局可读的
SQLite数据库如果需要使⽤数据库的搜索和数据管理功能，则可以使
⽤SQLite数据库存储机制
程序内部可以任意访问，外部程序不能访问
⽹络存储通过web服务器存储和获取数据基于web 服务器的设置
2.2 传输安全问题
学习型中国世纪成功论坛 • 不使⽤加密传输
最危险的是直接使⽤HTTP协议登录账户或交换数据。例如，攻击者在⾃⼰设置的钓鱼⽹络中配置DNS服务器，将软件要连接的服务器域名解析⾄攻击者的另⼀台服务器在，这台服务器就可以获得⽤户登录信息，或者充当客户端与原服务器的中间⼈，转发双⽅数据。
• 使⽤加密传输但忽略证书验证环节
如开发者在代码中不检查服务器证书的有效性，或选择接受所有的证书。例如，开发者可以⾃⼰实现⼀个X509TrustManager接⼝，将其中的CheckServerTrusted()⽅法实现为空，即不检查服务器是否
可信或者在SSLSoketFactory的实例中，通过setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIET)，接受所有证书。这可能是因为开发者使⽤了⾃⼰⽣成的证书，客户端发现证书没有和可信CA 形成信任链，出现了CertificateException等异常，从⽽不得不做出这种选择。这种做法可能导致的问题是中间⼈攻击。
我们在对敏感数据进⾏传输时应该采⽤基于SSL/TLS的HTTPS进⾏传输。由于移动软件⼤多只和固定的服务器通信，我们可以采⽤“证书锁定”（certificate pinning）⽅式在代码更精确地直接验证服务器是否拥有某张特定的证书。实现“证书锁定”的⽅法有⼆种：⼀种是实现
X509TrustManager接⼝，另⼀种则是使⽤keystore。具体可以参考Android开发⽂档中的HttpsURLConnection类的概述。
3. 组件安全
android应⽤内部的Activity、Service、Broadcast Receiver等组件是通过Intent通信的，组件间需要通信就需要在l⽂件中配置，不恰当的组件配置、组件在被调⽤时未做验证、在调⽤其他组件时未做验证都会带来风险。
可能产⽣的风险包括：
（1）恶意调⽤
（2）恶意接受数据
（3）仿冒应⽤，例如（恶意钓鱼，启动登录界⾯）
（4）恶意发送⼴播、启动应⽤服务。
（5）调⽤组件，接受组件返回的数据
（6）拦截有序⼴播
⽐如：调⽤暴露的组件发短信、微博等。
解决办法：
（1）最⼩化组件暴露
与戒
不参与跨应⽤调⽤的组件添加android:exported="false"属性，这个属性说明它是私有的，只有同⼀个应⽤程序的组件或带有相同⽤户ID 的应⽤程序才能启动或绑定该服务。
（2）设置组件访问权限
对参与跨应⽤调⽤的组件或者公开的⼴播、服务设置权限。只有具有该权限的组件才能调⽤这个组件。
（3）暴露组件的代码检查
Android 提供各种API来在运⾏时检查、执⾏、授予和撤销权限。这些API 是 t.Context 类的⼀部分，这个类提供有关应⽤程序环境的全局信息。
4. WebView
存在的漏洞：
恶意App可以注⼊JavaScript代码进⼊WebView中的⽹页，⽹页未作验证。
恶意⽹页可以执⾏JavaScript反过来调⽤App中注册过的⽅法，或者使⽤资源。
漏洞利⽤：
恶意程序嵌⼊Web App，然后窃取⽤户信息。
恶意⽹页远程调⽤App代码。更有甚者，通过Java Reflection调⽤Runtime执⾏任意代码。
解决⽅式：
1、如果⽆需与JS交互，请删除对addJavascriptInterface函数的调⽤；
2、在载⼊页⾯时对URL进⾏⽩名单判定，只有存在⽩名单中的域才允许导出或调⽤相关的Java类或⽅法。
5. SQL注⼊
使⽤字符串连接⽅式构造SQL语句就会产⽣SQL注⼊。
解决⽅法：使⽤参数化查询。
5. 其他漏洞
ROOT后的⼿机可以修改App的内购，或者安装外挂App等。
Logcat泄露⽤户敏感信息。
恶意的⼴告包插件（可能存在后门、WebView漏洞等）
UXSS漏洞：
UXSS漏洞可以绕过同源策略访问存储在Android应⽤⽬录/data/data/[应⽤包名]/下的所有内容。
如果产⽣该漏洞的是web浏览器，则攻击者可以利⽤该漏洞窃取浏览器存储的所有cookie信息以及其它信息。
测试代码：
解决⽅法：
2、客户端使⽤setAllowFileAccess(false)⽅法禁⽌webview访问本地域。详见：
3、客户端使⽤onPageStarted (WebView view, String url, Bitmap favicon)⽅法在跳转前进⾏跨域判断。
4、客户端对iframe object标签属性进⾏过滤。
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系统上的数据存储和数据传输进⾏加密保护，保证终端上数据能够安全地使⽤。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议