某黑盒 App 登录参数逆向分析

Android APP 常见漏洞

一、前言

​ 之前在学习 Android 逆向时更多地关注的是如何 Hook & 动、静态分析，忽略了关于 四大组件 这方面的常见漏洞，故写下此篇文章。

二、概述

Android 漏洞可能存在的点：

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

三、Android APP 常见安全漏洞

四大组件

​ 四大组件的安全问题很大一部分是由于组件设置成导出状态（android:exported=true）引起的。

​ Android 四大组件中，Activity，Service，BroadcastReceiver 广播接收器之间都可以通过 Intent 行通信，所以他们都存在由 Intent 传输数据引发的本地拒绝服务漏洞。

1. 背景知识：Android系统中的Intent机制负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述，系统则根据此Intent的描述，负责找到对应的组件，将Intent传递给调用的组件，并完成组件的调用。
2. 产生原理：Android应用本地拒绝服务漏洞源于程序处理Intent.getXXXExtra() 获取的数据时没有进行异常捕获，从而导致攻击者可通过向受害者应用发送此类空数据、异常或者畸形数据来达到使该应用崩溃的目的。
3. 危害：
   • 导致安全防护等应用的防护功能被绕过或失效（如杀毒应用、安全卫士、防盗锁屏等）。
   • 被竞争方应用利用并攻击，使得己方应用崩溃，造成不同程度的经济利益损失。
4. 防护：
   • 将不必要的组件设置为不导出，在 AndroidMenifest.xml 文件中，将相应组件的 android:exported 属性设置为 false，防止引起拒绝服务，尤其是杀毒、安全防护、锁屏防盗等安全应用。
   • 处理通过 Intent.getXXXExtra() 获取的数据时进行以下判断，同时用try-catch方式捕获所有异常，以防止应用出现拒绝服务漏洞：空指针异常、类型转换异常、数组越界访问异常、类未定义异常、其他异常。
5. 攻击代码示例：包括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基本上分为两种形式：

	1. **启动状态**

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

2. **绑定状态**

​ 当应用组件通过调用 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

1. 谨慎处理接收的 Intent 以及其携带的信息；

2. 私有 Activity 不应被其他应用启动且应该确保相对是安全的；

3. 当 Activity 返回数据时候需注意目标 Activity 是否有泄露信息的风险，同时谨慎处理 Activity 返回的数据，目的 Activity 返回的数据有可能是恶意应用伪造的；

4. 目标 Activity 十分明确时尽量使用显式 Intent；

5. 验证目标 Activity 是否属于恶意 App，以免受到 Intent 欺骗，可用hash 签名验证；

6. 尽可能的不发送敏感信息，应考虑到启动 public Activity 中 Intent 的信息均有可能被恶意应用窃取的风险；

7. 不需要被外部程序调用的组件应该添加 android:exported="false" 属性，这个属性说明它是私有的，只有同一个应用程序的组件或带有相同用户 ID 的应用程序才能启动或绑定该组件；

8. 对于希望 Activity 能够被特定的外部程序访问，可以为其设置访问权限，具体做法有以下两种：

   ①组件添加android：permission属性；

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

Service

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

Content Provider

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

Broadcast Receiver

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

默认设置漏洞

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

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

WebView的默认设置问题

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

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

1. Webview默认开启密码保存功能 mWebview.setSavePassword(true)，如果该功能未关闭，在用户输入密码时，会弹出提示框，询问用户是否保存密码，如果选择“是”，密码会被明文保存到 /data/data/com.package.name/databases/webview.db，如果手机被 root 之后，获取 root 权限的 APP 就可以任意读取私有目录下的文件去获取用户的密码，因此建议用户密码需要加密存储。
2. 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 忽略证书验证错误信息继续加载页面，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。

防护

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

忽略域名校验

原理

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

防护

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

WebView安全漏洞

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

WebView设置方面的安全风险

1. setJavaScriptEnabled()，默认为 false，即不允许执行JS代码。webview.getWebSettings().setavaScriptEnabled(true);
2. setPluginState()，它有三个状态值ON、ON DEMAND、OFF，默认为OFF。
3. setAllowFileAccess() 默认为true，即允许从 WebView 访问本地文件。
4. setAllowContentAccess() 默认为 true，即允许从 WebView 加载Content URL，读取 content provider 相关内容。
5. setAllowFileAccessFromFileURLs()，这个函数的作用是在 JS 没有禁用的情况下，设置是否允许 file 协议的 URL 访问其他 file 协议的URL 的文件内容。API15 及以下默认值为true，API16 及以上默认为false。
6. setAllowUniversalAccessFromFileURLs()，这个函数的作用是在 JS 没有禁用的情况下，设置是否允许 file 协议的 URL 访问其他任意来源的内容。
7. 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 文件，即可获取到被符号链接所指的文件。

防护

1. 将不必要导出的组件设置为不导出。

2. 如果应用的需要导出包含 Webview 的组件，禁止使用 File 域协议。

   myWebView.getSettings.setAllowFileAccess(false);

3. 如果需要使用 File 协议，禁止 File 协议调用 JavaScript。

   myWebView.getSettings.setavaScriptEnabled(false)

WebView安全防护

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

白名单绕过漏洞

签名白名单绕过

关于Android签名

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

1. MANIFEST.MF

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

2. CERT.SF

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

3. CERT.RSA

   会把之前生成的 CERT.SF 文件，用私钥计算出签名，然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。CERT.RSA 是一个满足 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.1\.163.com/2.html] 这个 URL 使用getHost 得到的域名是 192.168.0.1\.163.com，这样在判断时很容易判断为正常域名可以进行访问，但是在实际打开这个 URL 时，Android的 webview 会将 URL 解析为 [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] 所以此时并不能正常访问。 但是由于开发习惯，一般这个对域名进行校验的方法会作为一个公共方法使用，所以建议使用其他方法来判断。
对于使用 getHost 方式获取 url 进行白名单判断的方式，还有另外一种绕过方式就是 url 跳转，类似如下的URL跳转都是基于主站的跳转，即便是对于上面提到的这种白名单绕过方式进行了有效限制，但是还是可以进行绕过，由于很多公司对 url 跳转漏洞都不是很重视，所以结合 url 跳转漏洞进行的攻击在有的时候也可以达到令人惊奇的程度，危害还是非常严重的，比如说静默下载安装[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

其他

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

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

不安全的哈希/加密算法

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

弱加密算法

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

重放攻击风险

原理

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

防护

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

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

原理

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

防护

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

敏感数据泄露

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

ZIP解压缩漏洞

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

四、结语

​ 这块内容很多很杂，本人也只是做了一些浅显的学习总结，更多更深的内容还是得需要在真是开发生产中遇到并学习。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 1621925986@qq.com