Android APP常见安全漏洞

概述

Android漏洞可能存在的点：

协议——通信协议（本地、网络），协议大部分是由C/C++实现，存在以下安全问题：通信数据引发的逻辑漏洞；通信数据引发的缓冲区溢出等可能导致远程代码执行/拒绝服务的代码漏洞。
组件安全——Activity，Service服务,Content Provider内容提供者，BroadcastReceiver广播接收器中可能存在的安全问题，其中最主要的就是intent组件通信导致的拒绝服务/越权漏洞。
开放端口——可通过命令查看各APP运行时存在的开放端口，然后去逆向分析APP查看其在此开放端口上进行的操作，从而找寻可能的漏洞。
IPC（进程间通信）安全——同1。
文件读写安全/数据加密安全——Android平台上的隐私泄露也是一个值得关注的攻击面。

Android APP常见安全漏洞

四大组件

四大组件的安全问题很大一部分是由于组件设置成导出状态（android:exported=true）引起的。
Android 四大组件中，Activity，Service，BroadcastReceiver广播接收器之间都可以通过Intent进行通信，所以他们都存在由Intent传输数据引发的本地拒绝服务漏洞。

背景知识：Android系统中的Intent机制负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述，系统则根据此Intent的描述，负责找到对应的组件，将Intent传递给调用的组件，并完成组件的调用。
产生原理：Android应用本地拒绝服务漏洞源于程序处理Intent.getXXXExtra()获取的数据时没有进行异常捕获，从而导致攻击者可通过向受害者应用发送此类空数据、异常或者畸形数据来达到使该应用崩溃的目的。
危害：

导致安全防护等应用的防护功能被绕过或失效（如杀毒应用、安全卫士、防盗锁屏等）。
被竞争方应用利用并攻击，使得己方应用崩溃，造成不同程度的经济利益损失。

防护：

将不必要的组件设置为不导出，在AndroidMenifest.xml文件中，将相应组件的android:exported属性设置为false，防止引起拒绝服务，尤其是杀毒、安全防护、锁屏防盗等安全应用。
处理通过Intent.getXXXExtra()获取的数据时进行以下判断，同时用try-catch方式捕获所有异常，以防止应用出现拒绝服务漏洞：空指针异常、类型转换异常、数组越界访问异常、类未定义异常、其他异常。

攻击代码示例：包括NullPointerException异常、ClassCastException异常、IndexOutOfBoundsException异常、ClassNotFoundException异常。

Activity

组件导出导致钓鱼欺诈

原理

Android为了提高用户的用户体验，对于不同的应用程序之间的切换，基本上是无缝。他们切换的只是一个Activity，让切换的到前台显示，另一个应用则被覆盖到后台，不可见。Activity的概念相当于一个与用户交互的界面。而Activity的调度是交由Android系统中的AMS管理的。AMS即ActivityManagerService(Activity管理服务),各个应用想启动或停止一个进程，都是先报告给AMS。当AMS收到要启动或停止Activity的消息时，它先更新内部记录，在通知相应的进程运行或停止指定的Activity。当新的Activity启动，前一个Activity就会停止，这些Activity都保留在系统中年的Activity历史栈中。每有一个Activity启动，它就压入历史栈顶，并在手机上显示。当用户按下back键时，顶部Activity弹出，恢复前一个Activity，栈顶指向当前的Activity。由于Activity的这种特性，如果在启动一个Activity时，给它加入一个标志位FLAGACTIVITYNEW_TASK,就能使它置于栈顶并立马呈现给用户。如果这个Activity是用于盗号的伪装Activity，那么就会产生钓鱼安全事件或者是一个Activity中有webview加载，如果允许加载任意网页也有可能会产生钓鱼事件。

防护

如果当前的程序进入后台，则需要提示用户当前进程状态。

隐式启动intent包含敏感数据

Intent类型

显式 Intent：按名称（完全限定类名）指定要启动的组件。通常，您会在自己的应用中使用显式 Intent 来启动组件，这是因为您知道要启动的 Activity 或服务的类名。例如，启动新 Activity 以响应用户操作，或者启动服务以在后台下载文件。

创建显式 Intent 启动 Activity 或服务时，系统将立即启动 Intent 对象中指定的应用组件。

隐式 Intent ：不会指定特定的组件，而是声明要执行的常规操作，从而允许其他应用中的组件来处理它。例如，如需在地图上向用户显示位置，则可以使用隐式 Intent，请求另一具有此功能的应用在地图上显示指定的位置。

创建隐式 Intent 时，Android 系统通过将 Intent 的内容与在设备上其他应用的清单文件中声明的 Intent 过滤器进行比较，从而找到要启动的相应组件。如果 Intent 与 Intent 过滤器匹配，则系统将启动该组件，并向其传递 Intent 对象。如果多个 Intent 过滤器兼容，则系统会显示一个对话框，支持用户选取要使用的应用。

对于显式Intent，Android不需要去做解析，因为目标组件已经很明确，Android需要解析的是那些隐式Intent，通过解析，将Intent映射给可以处理此Intent的Activity、IntentReceiver或Service。

Service

概述

Service(服务)是一个一种可以在后台执行长时间运行操作而没有用户界面的应用组件。服务可由其他应用组件启动（如Activity），服务一旦被启动将在后台一直运行，即使启动服务的组件（Activity）已销毁也不受影响。此外，组件可以绑定到服务，以与之进行交互，甚至是执行进程间通信 (IPC)。例如，服务可以处理网络事务、播放音乐，执行文件 I/O 或与内容提供程序交互，而所有这一切均可在后台进行，Service基本上分为两种形式：

启动状态

当应用组件（如 Activity）通过调用 startService() 启动服务时，服务即处于“启动”状态。一旦启动，服务即可在后台无限期运行，即使启动服务的组件已被销毁也不受影响，除非手动调用才能停止服务，已启动的服务通常是执行单一操作，而且不会将结果返回给调用方。
绑定状态

当应用组件通过调用 bindService() 绑定到服务时，服务即处于“绑定”状态。绑定服务提供了一个客户端-服务器接口，允许组件与服务进行交互、发送请求、获取结果，甚至是利用进程间通信 (IPC) 跨进程执行这些操作。仅当与另一个应用组件绑定时，绑定服务才会运行。多个组件可以同时绑定到该服务，但全部取消绑定后，该服务即会被销毁。

危害

如果一个导出的 Service没有做严格的限制，任何应用可以去启动并且绑定到这个 Service上，取决于被暴露的功能，这有可能使得一个应用去执行未授权的行为，获取敏感信息或者是污染修改内部应用的状态造成威胁。

Broadcast receiver

概述

BroadcastReceiver是 Android的四大组件之一，这个组件涉及两个概念：广播发送者和广播接收者。这里的广播实际上指的就是 intent。当发送一个广播时，系统会将发送的广播 (intent)与系统中所有注册的符合条件的接收者的 IntentFilter进行匹配，若匹配成功，则执行相应接收者的 onReceive函数。可以通过两种方式注册广播接收器，一种是在Manifest.xml文件中通过标签静态注册，另一种是通过Context.registerReceiver()动态注册，指定相应的intentfilter参数。而动态注册的广播是默认导出的。

危害

发送广播时如果处理不当，恶意应用便可以嗅探、拦截广播，致使敏感数据泄露等；

原理：发送的intent没有明确指定接收者，而是简单的通过action匹配。恶意应用可注册一个广播接收者嗅探拦截这个广播。
防护：使用LocalBroadcastManager.sendBroadcast()发出的广播只能被app自身广播器接收。

如果接收广播时处理不当，便可导致拒绝服务攻击、伪造消息、越权操作等。

Content Provider

概述

Content Provider负责进行数据交互&共享，即跨进程通信

危害

信息泄露漏洞

如果对Content Provider的权限没有做好控制，就有可能导致恶意程序通过构造Content URI读取App的敏感数据。

SQL注入漏洞

对Content Provider进行增删改查操作时，程序没有对用户的输入进行过滤，未采用参数化查询的方式，可能导致sql注入攻击。

目录遍历漏洞

对外暴露的Content Provider组件实现了openFile()接口，并且没有对Content Provider组件的访问进行权限控制，也没有对访问的目标文件的Uri进行有效判断，第三方应用程序可以利用该接口进行文件目录遍历，访问任意可读文件。

四大组件的安全防护

Activity

谨慎处理接收的Intent以及其携带的信息；
私有Activity不应被其他应用启动且应该确保相对是安全的；
当Activity返回数据时候需注意目标Activity是否有泄露信息的风险，同时谨慎处理Activity返回的数据，目的Activity返回的数据有可能是恶意应用伪造的；
目标Activity十分明确时尽量使用显式Intent；
验证目标Activity是否属于恶意app，以免受到Intent欺骗，可用hash签名验证；
尽可能的不发送敏感信息，应考虑到启动public Activity中Intent的信息均有可能被恶意应用窃取的风险；
不需要被外部程序调用的组件应该添加android:exported="false"属性，这个属性说明它是私有的，只有同一个应用程序的组件或带有相同用户ID的应用程序才能启动或绑定该组件；
对于希望Activity能够被特定的外部程序访问，可以为其设置访问权限，具体做法有以下两种：

①组件添加android：permission属性；

android:permission:"android.perrmission.SEND SMS"
②protectionLevel权限声明；
android:protectionLevel="dangerous"

Service

私有的service尽量不定义intent-filter并且设置exported属性为false；
尽量用显式的方式启动service；
合作service需对合作方的app签名做校验；
Service接收到的数据需要谨慎处理；
内部service需使用签名级别的protectionLevel来判断是否为内部应用调用；
Service不应在onCreate时决定是否提供服务，应在onStartCommand/onBind/onHandleIntent等方法被调用时做判断；
当service有返回数据时，应判断接收数据的组件是否有信息泄露的风险；
尽量不发送敏感信息；

Content Provider

如果不需要与其他应用程序进行数据共享，就应该在manifest文件中设置android:exported="false"；
注意,在API Level低于8时，即使显式地声明了android:exported="false"，其它应用程序仍然可以访问对应的Content Provider，所以尽量避免使用Level低于8的API；
需要向外部提供数据的Content Provider需设置访问权限；
传递给ContentProvider的参数应该被视为不可信的输入，不应该在没有经过任何处理的情况下直接用于SQL查询；
避免使用SQLiteDatabase对象的execSQL()方法；

Broadcast Receiver

私有广播接收器设置android:exported="false"，尽量不配置intent-filter；
私有广播尽量使用LocalBroadcastManager动态注册和使用；
暴露的广播接收器需要对数据来源进行权限控制和身份验证；
广播接收器对于接收的数据要谨慎地使用多种异常来控制数据处理；
发送广播时如果包含敏感数据则需要显示意图，并通过setPackage()指定接收者包名；

默认设置漏洞

AndroidManifest.xml配置文件中默认设置相关问题

allowBackup默认设置风险（Android 2.1以上的系统可为App提供应用程序数据的备份和恢复功能，AndroidManifest.xml文件中的allowBackup属性值控制，其默认值为true。当该属性没有显式设置为false时，攻击者可通过adb backup和adb restore对App的应用数据进行备份和恢复。）
Debuggable默认设置风险
组件默认导出风险

WebView的默认设置问题

在 Android开发中，经常会使用 Webview来实现WEB页面的展示，在 Activity中启动自己的浏览器或者简单的展示一些在线内容等。

setAllowFileAccess()
setAllowContentAccess()
setAllowFileAccessFromFileURLs()
setAllowUniversalAccessFromFileURLs()
setSavePassword()

Webview默认开启密码保存功能 mWebview.setSavePassword(true)，如果该功能未关闭，在用户输入密码时，会弹出提示框，询问用户是否保存密码，如果选择“是”，密码会被明文保到/data/data/com.package.name/databases/webview.db，如果手机被root之后，获取roo权限的APP就可以任意读取私有目录下的文件去获取用户的密码，因此建议用户密码需要加密存储。
Android中默认mWebView.setAllowFileAccess(true)，在File域下，能够执行任意的JavaScript代码，同源策略跨域访问能够对私有目录文件进行访问等。APP对嵌入的 Webview未对file://形式的URL做限制，会导致隐私信息泄露，针对IM类软件会导致聊天信息、联系人等等重要信息泄露，针对浏览器类软件，则更多的是 cookie信息泄露。

网络相关

https通信安全漏洞

在Android中使用SSL/TLS协议，通过校验服务器端证书来实现安全通信。（这里指单向SSL校验，与之对应的是双向SSL校验，双向SSL指的是同时校验客户端和服务器端证书。）
https证书不校验漏洞：忽略SSL证书校验、忽略域名校验、证书颁发机构被攻击导致私钥泄露，导致中间人攻击，攻击者可通过中间人攻击，盗取账户密码明文、聊天内容、通讯地址、电话号码以及信用卡支付信息等敏感信息，甚至通过中间人劫持将原有信息替换成恶意链接或恶意代码程序，以达到远程控制、恶意扣费等攻击意图。

忽略SSL证书校验

原理

在自定义实现X509TrustManager时，checkServerTrusted中没有检查证书是否可信，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。
在重写 WebviewClient的 onReceivedSslError方法时，调用 proceed忽略证书验证错误信息继续加载页面，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。

防护

建议自定义实现X509TrustManager时，在 checkServerTrusted中对服务器信息进行严格校验。针对自定义 TrustManager，检查 checkServerTrusted()函数是否为空实现。
建议不要重写 TrustManager和 HostnameVerifier，使用系统默认的。
在重写 WebViewClient的。 onReceivedSslError方法时，避兔调用 proceed忽略证书验证错误信息继续加载页面。
禁止使用proceed()函数忽略证书错误，应该抛给系统进行安全警告。

忽略域名校验

原理

在自定义实现 HostnameVerifier时，没有在verify中进行严格证书校验，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。
在HostnameVerifier方法中使用ALLOW_ALL_HOSTNAME_VERIFIER，信任所有Hostname，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。

防护

在自定义实现 HostnameVerifier时，在verify中对Hostname进行严格校验。
建议在HostnameVerifier方法中使用STRICT_HOSTNAME_VERIFIER进行严格证书校验，避免使用ALLOW_ALL_HOSTNAME_VERIFIER。

WebView安全漏洞

远程代码执行漏洞
UXSS
Webview设置方面的安全风险
Webview忽略证书错误漏洞
Webview File域同源策略绕过漏洞

WebView设置方面的安全风险

setJavaScriptEnabled()，默认为false，即不允许执行JS代码。webview.getWebSettings().setavaScriptEnabled(true);
setPluginState()，它有三个状态值ON、ON DEMAND、OFF，默认为OFF。
setAllowFileAccess()默认为true，即允许从WebView访问本地文件。
setAllowContentAccess()默认为true，即允许从WebView加载Content URL，读取content provider相关内容。
setAllowFileAccessFromFileURLs()，这个函数的作用是在JS没有禁用的情况下，设置是否允许file协议的URL访问其他file协议的URL的文件内容。API15及以下默认值为true，API16及以上默认为false。
setAllowUniversalAccessFromFileURLs()，这个函数的作用是在JS没有禁用的情况下，设置是否允许file协议的URL访问其他任意来源的内容。
setSavePassword()默认值为true，这个函数的作用是设置是否允许WebView自动保存密码。

Webview File域同源策略绕过漏洞

原理

浏览器有一个很重要的概念——同源策略(Same-Origin Policy)。所谓同源是指，域名，协议，端口相同。不同源的客户端脚本(JavaScript、 ActionScript)在没明确授权的情况下，不能读写对方的资源。简单的来说，浏览器允许包含在页面A的脚本访问第二个页面B的数据资源，这一切是建立在A和B页面是同源的基础上。同源策略是由 Netscape提出的一个著名的安全策略，现在所有支持 JavaScript的浏览器都会使用这个策略。
在Android系统中，APP访问网页一般是使用浏览器或者是使用了 Android系统内置的 webview组件。如果 Webview没有禁止使用file域并且Webview打开了对 JavaScript的支持。通过 Webview对 javascript
的延时执行和将当前Html文件删除掉并软连接指向其他文件就可以读取到被符号链接所指的文件，然后通过 JavaScript再次读取HTML文件，即可获取到被符号链接所指的文件。

防护

将不必要导出的组件设置为不导出。
如果应用的需要导出包含 Webview的组件，禁止使用File域协议。

myWebView.getSettings.setAllowFileAccess(false);
如果需要使用File协议，禁止File协议调用 JavaScript。

myWebView.getSettings.setavaScriptEnabled(false)

WebView安全防护

手机厂商把手机内置的WebView与google保持更新一致。
手机厂商把手机内置的浏览器漏洞修补程度要与Google官方保持一致，并且检测个性化自定义的暴露的API接口。
手机浏览器厂商浏览器漏洞修补程度要与 Google官方保持一致，并且检测个性化自定义的暴露的API接口。
APP开发人员注意 webview的各项默认设置。
用户随时把手机的内置 webview以及使用的浏览器更新到最新版本。

白名单绕过漏洞

签名白名单绕过

关于Android签名

Android签名apk之后，会有一个META-INF文件夹，这里有三个文件:

MANIFEST.MF

存储的是每一个文件对应的SHA1(或者SHA256)消息摘要算法提取出该文件的摘要然后进行BASE64编码。
CERT.SF

计算这个MANIFEST.MF文件的整体SHA1值，再经过BASE64编码后，记录在CERT.SF主属性块(在文件头上)的SHA1-Digest-Manifest属性值值下。
逐条计算MANIFEST.MF文件中每一个块的SHA1，并经过BASE64编码后，记录在CERT.SF中的同名块中，属性的名字是SHA1-Digest。
CERT.RSA

会把之前生成的 CERT.SF文件，用私钥计算出签名,然后将签名以及包含公钥信息的数字证书一同写入CERTRSA 中保存。CERTRSA是一个满足PKCS7格式的文件。

除了RSA格式的文件还有 CERT.DSA/EC两种格式，Android支持DSA、RSA、EC三种加密算法进行签名，都是用来保存用私钥计算出 CERT.SF文件的数字签名、证书发布机构、有效期、公钥、所有者、签名算法等信息。
正常情况下，一个APK中只会生成一个 CERT.RSA/DSA/EC签名文件。但若在APK压缩包中加入其他的签名文件，即可同时存在两个或两个以上的签名文件。

URL白名单绕过漏洞

手机应用在特定环境下需要打开外部传入的URL，或者使用外部传入的URL去下载。为了对打开或下载的URL做控制，就需要对域名进行校验。
对URL的域名进行校验，一般习惯使用系统API，getHost来获取域名进行字符串比较，但是由于getHost这个系统API的设计缺陷，使其可以被绕过。

[http://192.168.0.11\.163.com/2.html](http://192.168.0.11\.163.com/2.html) 这个URL使用getHost得到的域名是192.168.0.11\.163.com，这样在判断是很容易判断为正常域名可以进行访问，但是在实际打开这个URL时，android的webview会将URL解析为[http://192.168.0.1/.163.com/2.html](http://192.168.0.1/.163.com/2.html) 来访问，这样.163.com就变为了192.168.0.1这个IP地址下的一个path。这样webview就可能被打开一些不受控制的网页。但是在使用HttpClient等API进行访问时会解析为[http://192.168.0.1.163.com/2.html](http://192.168.0.1.163.com/2.html) 所以此时并不能正常访问。但是由于开发习惯，一般这个对域名进行校验的方法会作为一个公共方法使用，所以建议使用其他方法来判断。
对于使用getHost方式获取url进行白名单判断的方式，还有另外一种绕过方式就是url跳转，类似如下的URL跳转都是基于主站的跳转，即便是对于上面提到的这种白名单绕过方式进行了有效限制，但是还是可以进行绕过，由于很多公司对url跳转漏洞都不是很重视，所以结合url跳转漏洞进行的攻击在有的时候也可以达到令人惊奇的程度，危害还是非常严重的，比如说静默下载安装[http://mbs.hao.163.cn/?c=redirect&ur=http://tu.623.cn/7vNo](http://mbs.hao.163.cn/?c=redirect&ur=http://tu.623.cn/7vNo.)

Socket远程连接漏洞

如果手机开放端口，但是缺少对发送者的身份验证或者是存在权限控制缺陷，导致黑客拿下这个端口的权限，便可以获得手机此端口开放的所有功能。此漏洞只与App有关，不受系统版本影响。

APK升级漏洞

APP 升级流程	隐患	漏洞危害
升级API	升级API未加密	返回恶意下载地址，可下载恶意APK
下载API	下载API未加密	下载路径被篡改，可下载恶意APK
程序安装API	APK本地路径篡改	安装错误的APK

其他

加密算法是否存在安全缺陷

客户端与服务器通信或数据存储往往采用一些加密算法来保障数据的安全，但是这些算法本身可能存在缺陷。

不安全的哈希/加密算法

MD5哈希算法易遭到已知的哈希冲突攻击。哈希算法用于确保数据完整性（例如，文件签名或数字证书）时尤其易被攻击。在这种情况下，攻击者可能会生成两个独立的数据块，以便在不更改哈希值或使相关数字签名无效的情况下，将良性数据替换为恶意数据。
DES 加密使用的密钥强度较低，可能在一天内被暴力破解。
RC2 加密容易遭受与密钥相关的攻击，攻击者可以通过这些攻击找出所有密钥值之间的数学关系。

弱加密算法

TripleDES 等加密算法和 SHA1 及 RIPEMD160 等哈希算法被视为弱加密算法。
这些加密算法不能与更现代的对应算法提供同样多的安全保证。
与更现代的哈希算法相比，加密哈希算法 SHA1 和 RIPEMD160 提供的冲突抗性较低。与更现代的加密算法相比，加密算法 TripleDES 提供的安全位数更少。

重放攻击风险

原理

重放攻击，是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。攻击者利用网络监听或者其他方式盗取认证凭据，之后再把它重新发给认证服务器。

防护

建议在客户端与服务端通信时加上时间戳或判断是否已登录过等条件，防止重放攻击。

业务接口是否存在任意权限调用

原理

在正常的业务中，敏感功能的接口需要对访问者的身份进行验证，验证通过后才允许调用接口进行操作。接口未做身份验证或身份校验不严，可能导致非授权访问或越权调用。

防护

建议每个用户登陆后使用随机id进行标识，随时更换新id或在通信过程中使用更多参数如时间戳、数字签名等防止用户越权获取到其他用户的订单等信息。采用加密通信如https安全传输也能在一定程度上解决该问题。
建议在本地做好输入数据的校验，在通信过程中应采用多个参数对某次通信进行标识和记录。保证参数的随机性和机密性，防止攻击者构造出针对系统健壮性进行攻击的请求数据。

敏感数据泄露

LogCat输出敏感信息
敏感数据明文存储于sdcard
数据库敏感数据明文存储
Shared preference全局可读写
敏感信息硬编码
HTTP敏感信息明文传输

ZIP解压缩漏洞

ZIP压缩包文件中允许存在../的字符串，攻击者可通过精心构造ZIP文件，利用多个../从而改变ZIP包中某个文件的存放位置，覆盖替换掉应用原有的文件。如果被覆盖掉的文件是so文件、dex文件或者odex文件，轻则产生本地拒绝服务漏洞，影响应用的可用性，重则可能造成任意代码执行漏洞，危害应用用户的设备安全和信息安全。比如“寄生兽”漏洞，海豚浏览器远程命令执行漏洞，三星默认输入法远程代码执行等。