移动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-jarAXMLPrinter2.jarxxxxx.xmlxxxxx.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.batclasses.dex然后你的目录里会多一个jar包多了一个classes-dex2jar.jar的文件然后在用jd-gui把jar包打开，最终apk的代码就这样被剥离出来了2.1.2、检测方法通过反编译工具看是否能够对APP进行反编译2.1.3、修复方法采用加密和混淆技术达到反编译保护。混淆技术作用是增加了用户反编译后阅读代码的难度。2.2、APP二次打包2.2.1二次打包描述“AndroidAPP二次打包”则是盗版正规AndroidAPP，破解后植入恶意代码重新打包。不管从性能、用户体验、外观它都跟正规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组件、contentprovider组件和broadcastreceiver组件。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组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。ContentProvider组件（1）android平台提供了ContentProvider使一个应用程序的指定数据集提供给其他应用程序。其他应用可以通过ContentResolver类从该内容提供者中获取或存入数据。（2）只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处是统一数据访问方式。（3）ContentProvider实现数据共享。ContentProvider用于保存和获取数据，并使其对所有应用程序可见。这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。broadcastreceiver（1）你的应用可以使用它对外部事件进行过滤，只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力，例如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。（2）广播接收者的注册有两种方法，分别是程序动态注册和AndroidManifest文件中进行静态注册。（3）动态注册广播接收器特点是当用来注册的Activity关掉后，广播也就失效了。静态注册无需担忧广播接收器是否被关闭，只要设备是开启状态，广播接收器也是打开着的。也就是说哪怕app本身未启动，该app订阅的广播在触发时也会对它起作用。四大组件总结（1）4大组件的注册4大基本组件都需要注册才能使用，每个Activity、service、ContentProvider都需要在AndroidManifest文件中进行配置。AndroidManifest文件中未进行声明的activity、服务以及内容提供者将不为系统所见，从而也就不可用。而broadcastreceiver广播接收者的注册分静态注册（在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，表示此组件不可以被外部应用调用。只有同一个应用的组件或者有着同样userID的应用可以3、AndroidManifest.xml文件中activity组件里面没有设置android:exported属性，但是有intent-filter，则exported默认属性为true，true表示此组件可以被外部应用调用。4、AndroidManifest.xml文件中activity组件里面没有设置android:exported属性，也没有设置intent-filter，则exported默认属性为false，false表示此组件不可以被外部应用调用。只有同一个应用的组件或者有着同样userID的应用可以备注：采用drozer工具可以进行检测组件是否存在导出风险2.3.3、修复建议(1)如果应用的Service组件不必要导出，或者组件配置了intentfilter标签，建议显示设置组件的“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_接口引起远程代码执行漏洞在Android3.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.Android4.2版本之后Google在Android4.2版本中规定对被调用的函数以@JavascriptInterface进行注解从而避免漏洞×××B2.Android4.2版本之前在Android4.2版本之前采用拦截prompt（）进行漏洞修复。searchBoxJavaBridge_接口引起远程代码执行漏洞删除se