[转]移动APP安全测试
1 移动App安全风险分析
1.1 安全威胁分析
安全威胁从三个不同环节进行划分，主要分为客户端威胁、数据传输端威胁和服务端的威胁。
1.2 面临的主要风险
1.3 Android测试思维导图
1.4 反编译工具
有两种反编译方式，dex2jar和apktool，两个工具反编译的效果是不一样的，dex2jar反编译出java源代码，apktool反编译出来的是java汇编代码。
dex2jar主要是用来把之前zip解压出来的classed.dex转成jar包的
jd-gui主要是用来打开Jar包的
2 本地客户端安全
2.1 反编译保护
2.1.1 问题描述
APP源代码对于一个公司是非常重要的信息资源，对APP的保护也尤为重要，APP的反编译会造成源代码被恶意者读取，以及APP的逻辑设计，
反编译方法
我们一般想要反编译一个apk，无非就是想获得三样东西：图片资源、XML资源、代码资源
一. 图片资源获取
首先准备一个apk，这里是一个.apk后缀的文件，我们先把后缀改成,zip，打开zip文件在res目录下，我们就可以获取到我们需要的图片了。
二. XML资源获取
我们可以在刚刚打开的zip文件目录下看到很多.xml的文件，这个xml文件是无法直接打开的，当你尝试着打开的时候都是乱码或者是空白，那么我们要如何获取到这个xml资源呢，这时候就需要借助一个jar包，就是它，axmlprinter2.jar，这个东西你只要百度下，就能搜到。然后 你把他放跟你解压出来的xml放在同级目录下，用cmd命令找到这个目录，
我这边的示例是将xml放在了E盘，大家根据情况,cd到自己解压出来的目录下，然后执行
java -jar AXMLPrinter2.jar xxxxx.xml>xxxxx.txt
这个时候你就能获取到xml里的东西啦
三. 代码资源获取
这个重中之重了，这也是我们主要想要获取到的东西。但是存在一点，这里能够正确反编译出来的只有未加密或者没有混淆的代码，如果想要反编译一些加密或者混淆后代码，俺们就需要其他途径解决了
首先要准备两样东西：dex2jar.rar和jd-gui.zip这两个工具。
dex2jar主要是用来把之前zip解压出来的classed.dex转成jar包的
jd-gui主要是用来打开Jar包的
dex2jar用法：
把dex2jar 解压后，然后将之前zip的classes.dex放到 dex2jar目录下，
注意，必须要跟dex2jar.bat是同级目录。
然后又要用到cmd，cd 到dex2jar目录下，打命令行
dex2jar.bat classes.dex
然后你的目录里会多一个jar包
多了一个 classes-dex2jar.jar的文件
然后在用jd-gui把jar包打开，最终apk的代码就这样被剥离出来了
2.1.2 检测方法
通过反编译工具看是否能够对APP进行反编译
2.1.3 修复方法
采用加密和混淆技术达到反编译保护。
混淆技术作用是增加了用户反编译后阅读代码的难度。
2.2 APP二次打包
2.2.1 二次打包描述
“Android APP二次打包”则是盗版正规Android APP，破解后植入恶意代码重新打包。不管从性能、用户体验、外观它都跟正规APP一模一样但是背后它确悄悄运行着可怕的程序，它会在不知不觉中浪费手机电量、流量，恶意扣费、偷窥隐私等等行为。
面对二次打包不少公司都有自己的防范措施，知名公司的APP几乎都是自己在程序内部做过处理防止其APP被二次打包，一旦打包后重新运行则程序自动退出。接下来，我就来详解一下如何防止APP被二次打包。
要实现代码内部防止APP被二次打包首先得了解APK的机器识别原理，APK的唯一识别是依靠包名和签名来做鉴定的，类似豌豆夹的洗白白、360手机卫士等安全软件对APK的山寨识别，他们就是依赖包名来确定APK然后通过签名来确定其是否山寨。所以说自己的程序内部在启动的时候可以通过获取APK本身的签名然后和正确的签名做对比来识别自己是否被二次打包。
2.2.2 防二次打包检测方法
利用二次打包工具对APP进行二次打包，看APP能否成功打包运行，如果重新打包后无法运行程序说明有防二次打包安全措施。
2.2.3 防二次打包修复方法
采用签名的方法进行保护：获取二次打包后APK的签名与正确的APK签名做对比，判断APK程序是否进行过二次打包。
建议：客户端使用从属方证书进行签名后进行发布而不是使用第三方开发商的证书进行签名，以防开发商内部监管异常，证书滥用的情况出现。
2.3 组件导出安全
2.3.1 四大组件描述
Android主要包含4大组件，分别是activity组件、service组件、content provider组件和broadcast receiver组件。
Activity组件
（1）一个Activity通常就是一个单独的屏幕（窗口）。
（2）Activity之间通过Intent进行通信。
（3）android应用中每一个Activity都必须要在AndroidManifest.xml配置文件中声明，否则系统将不识别也不执行该Activity。
Service组件
(1)service用于在后台完成用户指定的操作。
(2)开发人员需要在应用程序AndroidManifest.xml配置文件中声明全部的service，使用<service></service>标签。
(3)Service通常位于后台运行，它一般不需要与用户交互，因此Service组件没有图形用户界面。Service组件需要继承Service基类。Service组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。
Content Provider组件
（1）android平台提供了Content Provider使一个应用程序的指定数据集提供给其他应用程序。其他应用可以通过ContentResolver类从该内容提供者中获取或存入数据。
（2）只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处是统一数据访问方式。
（3）ContentProvider实现数据共享。ContentProvider用于保存和获取数据，并使其对所有应用程序可见。这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。
broadcast receiver
（1）你的应用可以使用它对外部事件进行过滤，只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力，例如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。
（2）广播接收者的注册有两种方法，分别是程序动态注册和AndroidManifest文件中进行静态注册。
（3）动态注册广播接收器特点是当用来注册的Activity关掉后，广播也就失效了。静态注册无需担忧广播接收器是否被关闭，只要设备是开启状态，广播接收器也是打开着的。也就是说哪怕app本身未启动，该app订阅的广播在触发时也会对它起作用。
四大组件总结
（1）4大组件的注册
4大基本组件都需要注册才能使用，每个Activity、service、Content Provider都需要在AndroidManifest文件中进行配置。AndroidManifest文件中未进行声明的activity、服务以及内容提供者将不为系统所见，从而也就不可用。而broadcast receiver广播接收者的注册分静态注册（在AndroidManifest文件中进行配置）和通过代码动态创建并以调用Context.registerReceiver()的方式注册至系统。需要注意的是在AndroidManifest文件中进行配置的广播接收者会随系统的启动而一直处于活跃状态，只要接收到感兴趣的广播就会触发（即使程序未运行）。
（2）4大组件的激活
内容提供者的激活：当接收到ContentResolver发出的请求后，内容提供者被激活。而其它三种组件activity、服务和广播接收器被一种叫做intent的异步消息所激活。
2.3.2 组件安全检查方法
1、 AndroidManifest.xml文件中activity组件里面有设置android:exported为true，表示此组件可以被外部应用调用。
2、 AndroidManifest.xml文件中activity组件里面有设置android:exported为false，表示此组件不可以被外部应用调用。只有同一个应用的组件或者有着同样user ID的应用可以
3、 AndroidManifest.xml文件中activity组件里面没有设置android:exported属性，但是有intent-filter，则exported默认属性为true，true表示此组件可以被外部应用调用。
4、 AndroidManifest.xml文件中activity组件里面没有设置android:exported属性，也没有设置intent-filter，则exported默认属性为false，false表示此组件不可以被外部应用调用。只有同一个应用的组件或者有着同样user ID的应用可以
备注：采用drozer工具可以进行检测组件是否存在导出风险
2.3.3 修复建议
(1)如果应用的Service组件不必要导出，或者组件配置了intent filter标签，建议显示设置组件的“android:exported”属性为false
(2)如果组件必须要提供给外部应用使用，建议对组件进行权限控制
2.4 Webview漏洞
2.4.1 WebView任意代码执行漏洞
2.4.1.1 描述
出现该漏洞的原因有三个
WebView 中 addJavascriptInterface（） 接口
WebView 内置导出的 searchBoxJavaBridge_对象
WebView 内置导出的 accessibility 和 accessibilityTraversalObject 对象
addJavascriptInterface 接口引起远程代码执行漏洞
JS调用Android的其中一个方式是通过addJavascriptInterface接口进行对象映射, 当JS拿到Android这个对象后，就可以调用这个Android对象中所有的方法，包括系统类（java.lang.Runtime 类），从而进行任意代码执行。
searchBoxJavaBridge_接口引起远程代码执行漏洞
在Android 3.0以下，Android系统会默认通过searchBoxJavaBridge_的Js接口给 WebView 添加一个JS映射对象：searchBoxJavaBridge_对象
该接口可能被利用，实现远程任意代码。
accessibility和 accessibilityTraversal接口引起远程代码执行漏洞
问题类似以上
2.4.1.2 检测方法
addJavascriptInterface 接口引起远程代码执行漏洞
检查是通过addJavascriptInterface接口进行对象映射
searchBoxJavaBridge_接口引起远程代码执行漏洞
检查是否通过searchBoxJavaBridge_的Js接口给 WebView 添加一个JS映射对象
accessibility和 accessibilityTraversal接口引起远程代码执行漏洞
问题类似以上
2.4.1.3 修复建议
addJavascriptInterface 接口引起远程代码执行漏洞
B1. Android 4.2版本之后
Google 在Android 4.2 版本中规定对被调用的函数以 @JavascriptInterface进行注解从而避免漏洞×××
B2. Android 4.2版本之前
在Android 4.2版本之前采用拦截prompt（）进行漏洞修复。
searchBoxJavaBridge_接口引起远程代码执行漏洞
删除searchBoxJavaBridge_接口
// 通过调用该方法删除接口
removeJavascriptInterface（）；
accessibility和 accessibilityTraversal接口引起远程代码执行漏洞
删除accessibility和 accessibilityTraversal接口
2.4.2 密码明文存储漏洞
2.4.2.1 描述
WebView默认开启密码保存功能：
mWebView.setSavePassword(true)
开启后，在用户输入密码时，会弹出提示框：询问用户是否保存密码；
如果选择”是”，密码会被明文保到 /data/data/com.package.name/databases/webview.db 中，这样就有被盗取密码的危险
2.4.2.2 检测方法
方法1、用户输入密码时看是否有弹出提示框，询问用户是否保存密码，如果有询问则表示存在漏洞，否则不存在。
方法2、检查代码中setSavePassword的值是否为false。
2.4.2.3 修复建议
关闭密码保存提醒
WebSettings.setSavePassword(false)
2.5 数据安全-本地敏感信息安全
2.5.1 APP所在目录的文件权限
2.5.1.1 问题描述
测试客户端APP所在目录的文件权限是否设置正确，非root账户是否可以读，写，执行APP目录下的文件。
来源 http://www.51testing.com/html/36/n-4456636.html
---------------------
作者：凯宾斯基
来源：CNBLOGS
原文：https://www.cnblogs.com/kaibindirver/p/10240728.html
版权声明：本文为作者原创文章，转载请附上博文链接！
内容解析By：CSDN,CNBLOG博客文章一键转载插件
