Android APP安全测试Checklist
前言
此文档旨在大家提供Android平台APP安全风险与漏洞相关的一般性Checklist，保障安全评估测试的基础质量与效率。
配置安全
发布状态检查
该类漏洞的审查场景：发布的代码未启用代码混淆、未关闭调试模式、未关闭不必要的日志输出、或者含有内网IP地址等信息 |
漏洞类型说明：
发布状态检查：如果APP未启用代码混淆或者其他抵抗分析的机制，或者在AndroidManifest.xml中定义了android:debuggable为true，或者没有限制日志输出的级别可能导致攻击者更容易地分析APP的运行机制，更方便地发现其中潜在的安全漏洞，以及信息泄露的风险。如果APP发布时未移除代码中保存的公司内部IP地址或域名信息，也将导致公司内网信息泄露。
审核点及方法：综合分析判断APP是否在发布前进行了充分的检查。
黑盒方法：利用dex2jar等工具对apk文件进行逆向，观察代码是否被混淆。分析AndroidManifest.xml文件，检查android:debuggable是否设置为true（缺省为false），通过logcat观察日志输出，在源码与xml文件中查找是否泄露公司敏感信息。
权限申请
该类漏洞的审查场景：APP权限申请 |
漏洞类型说明：
关于权限申请问题，其实不能算作是漏洞，而是一个安全设计原则，即权限分配最小化原则，APP申请权限应当遵循最小化原则，禁止申请不必要的冗余权限。
自定义权限
该类漏洞的审查场景：APP自定义权限 |
漏洞类型说明：
根据官方建议[1]，尽量避免自定义权限。如果必须自定义权限，建议保护级别设定为"Signature"。原因是保护级别为"Dangerous"的权限，其他APP可能也会申请该权限，而这些特定权限的说明可能会让用户困惑，而用户感到困惑时，通常忽视权限申请直接批准。
审核点及方法：检查AndroidManifest.xml文件中是否通过permission定义了权限，检查这些权限的protectionLevel是否为signature，若否，那么这些权限很可能被第三方申请。可进一步考察这些权限用于保护的功能，评估权限被第三方APP获取后可能造成的危害。
签名有效性校验
该类漏洞的审查场景：对APK文件进行反编译之后重新打包签名安装 |
漏洞类型说明：
签名有效性校验：如果APP在实现逻辑中缺乏对签名文件合法性的校验，黑客可以对APK文件反编译（可利用apktool工具d选项），并按照自己的意图对APK代码进行篡改，然后将篡改后的文件重新编译打包（可利用apktool工具的b选项），最后使用自定义的签名文件对打包APK文件签名（可利用keytool，jarsigner，zipalign工具）。这样，黑客可以向APP中植入恶意代码，并将重新编译打包的APK文件分发出去。
审核点及方法：判断APP的实现逻辑中是否对签名文件的合法性进行校验。
黑盒方法：将原始APK反编译，篡改其中的代码，重新编译打包APK，并用自定义生成的签名文件对其签名，安装APK，验证其是否能正常运行，若APP能正常运行，说明其实现中缺乏对签名有效的校验。
数据安全
存储安全
该类漏洞的审查场景：APP数据本地存储方式 |
漏洞类型说明：
数据存储安全：分析APP本地数据存储的安全，主要从三个方面考虑：① 高度敏感数据禁止存储在客户端（比如用户密码）；② 敏感数据必须设置为私有访问权限（禁止使用Context.MODE_WORLD_READABLE、Context.MODE_WORLD_WRITEABLE模式创建私有文件）；③ 禁止向外部存储设备（SD卡）写入敏感信息，对来自外部存储设备的数据，处理前必须校验数据的完整性、合法性。
- 场景：/data/data/
目录
审核点及方法：/data/data/
/data/data/
可以看到loginshare.json的访问权限是第三方可读的，这样系统中已安装的任意APP都可以访问到loginshare.json中的内容，导致敏感信息泄露。
黑盒方法：通过adb shell连接Android模拟器或者测试机（要求拥具备root访问权限），进入对应的/data/data/
- 场景：数据存储在外部设备（如：SD卡）
审核点及方法：对于外部存储设备，存储于其上的数据是全局可读的，任意APP都可以访问外部存储设备上的任意文件内容，因此，必须确保敏感信息不会存储在外部存储设备中。
黑盒方法：利用adb工具分析APP在外部存储设备中存储的数据，确保不包含敏感信息。
关于数据存储的安全，有些类型的APP会从外部存储设备中读取数据并加载执行，由于外部存储设备中的内容可以被任意APP操纵篡改，因此，APP在处理来自外部存储的数据之前，必须校验其完整性。
传输安全
该类漏洞的审查场景：APP通过网络发送或接收敏感信息，例如登录口令、用户隐私等，或者是通过网络下发的数据执行某些敏感操作 |
漏洞类型说明：
由于移动设备经常通过公共的Wifi热点上网，面临多种网络层面的威胁，例如网络窃听、网络劫持等，因此需要对敏感数据加密，并且对接收到的重要数据进行完整性校验。
如果APP自身实现了加密以及完整性校验的机制，那么需要注意其中是否存在安全缺陷，例如密钥管理是否安全（详见下面的章节），算法是否有缺陷等。
通常的做法是通过HTTPS来避免网络窃听与劫持，并且APP需要严格检查服务器端的证书，具体来讲，包括两个关键检查：
1）检查证书是否来自一个可信的签名机构：可以是自签名的证书，或者是Android系统信任的CA，这通常由TrustManager完成；
2）检查证书是否与服务器的Hostname匹配，这通常由hostnameVerifier完成。
但开发者为了方便，往往屏蔽了上述两个检查，导致APP信任任意的证书，这种情况下，攻击者可以进行中间人攻击解密或篡改HTTPS的数据，并且APP也无法抵抗DNS劫持。
审核点及方法：黑盒审核方法为通过网络分析工具（Tcpdump，Fiddler等）分析APP发送接收的数据包，观察其中是否有明文传输的敏感信息。如果有加密传输的敏感信息，进一步分析其加密算法与密钥管理机制。如果是通过HTTPS传输，观察是否可被Fiddler解密，如果可以，代表可进行中间人攻击。白盒审核方法为检查HTTP传输部分的代码，重点考察代码中是否设置自定义的TrustManager并且许可所有的服务器证书（详见代码示范），是否设置ALLOW_ALL_HOSTNAME_VERIFIER来允许所有Hostname（详见代码示范）：
不安全的TrustManager示范1：重写一个空的checkServerTrusted，导致任意服务器证书都不会抛出异常，视为合法
TrustManager tm = new X509TrustManager() {
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { }
};
不安全的TrustManager示范2：在checkServerTrusted中仅仅利用checkValidity检查了证书是否过期，任意未过期的证书，无论其签名机构是否可信，均视为合法证书：
public class EasyX509TrustManager implements X509TrustManager {
public void checkServerTrusted(X509Certificate[] certificates,
String authType) throws CertificateException {
if ((certificates != null) && (certificates.length == 1)) {
certificates[0].checkValidity();
} else {
standardTrustManager.checkServerTrusted(certificates, authType);
}
}
不安全的hostnameVerifer示范：设置一个允许所有Hostname的Verifier，攻击者只要拥有一个Android系统信任的证书，不论其颁发给谁，都被视为合法证书：
SSLSocketFactory localSSLSocketFactory = SSLSocketFactory.getSocketFactory();
localSSLSocketFactory.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
日志信息泄露
该类漏洞的审查场景：日志记录中泄露了敏感信息，可被第三方APP读取 |
漏洞类型说明：
注意日志是公有资源，所有拥有READ_LOGS权限的APP都有权限阅读全局日志数据，所以需要避免将敏感信息，例如用户登录口令，BDUSS Cookie等信息输出到日志中。
http://wooyun.org/bugs/wooyun-2010-024701
http://wooyun.org/bugs/wooyun-2010-025617
审核点及方法：黑盒审核方法为通过logcat或其他工具观察APP运行时的日志信息，检查其中是否有敏感信息。白盒审核方法为检查APP日志输出机制，在APP发布后尽量统一关闭不必要的日志输出，如果发布后实际有效的日志输出点过多，需要一一排查是否泄露敏感信息。
Intent信息泄露
该类漏洞的审查场景：隐式Intent中泄露了敏感信息，可被第三方APP读取 |
漏洞类型说明：
APP可能需要通过Intent来传递一些数据，但如果Intent中包含了敏感信息，且未明确指定接收方（隐式Intent）以及权限，那么第三方APP可以注册对应的Intent Filter来读取其中的敏感信息。
审核点及方法：黑盒审核方法为通过动态分析工具（例如Introspy, Xposed等）来观察运行时的IPC数据，检查其中是否含有敏感信息，且未指明接收方，也未明确权限。白盒审核方法为检查所有隐式Intent的发送点，检查是否包含敏感信息，若有敏感信息，继续检查是否声明了接收方的权限。
密钥管理
该类漏洞的审查场景：APP对数据进行了加密存储/传输，但没有较好的密钥管理方法，导致密钥泄露，数据被解密 |
漏洞类型说明：
APP在存储/传输敏感数据时，可能采用对称加密算法（AES, 3DES等）或非对称算法（RSA）对数据进行加密。如果未落实安全的密钥管理方案，可能导致密钥泄露。（这里需要注意区分非对称密钥算法的公钥与私钥，其公钥可以公开，而私钥需要保密）
常见的不安全密钥管理方法包括：
将对称密钥或私钥写死在配置或代码中，所有APP使用同一个对称密钥加密。这导致所有APP的密钥相同。攻击者可通过逆向分析出密钥，从而完成数据解密。
通过网络下发明文的对称密钥或私钥，攻击者通过网络窃听读取密钥，从而对后续传输的加密数据进行解密。
审核点及方法：黑盒审核方法为通过动态分析工具（例如Introspy, Xposed等）来观察运行时的加解密或创建Key等信息，观察APP所使用的加密算法以及密钥，同时结合网络分析工具（例如Tcpdump, Fiddler等）分析传输的数据，观察其中是否传输加密数据传输或者明文密钥。如果对称密钥一直固定，那么很可能写死在代码或配置文件中，可进一步搜索反编译的代码或配置文件，分析密钥生成机制。
组件安全
Android平台的APP主要由四类基本的组件构成，分别是：Activities组件、Services组件、Content providers组件、Broadband receivers组件。
Activities组件用于提供用户交互接口，APP中的可视界面基本都是由Activities组件实现。
Services组件运行于系统后台，一般用于执行长时间操作或者远程进程工作，不会提供用户交互界面。
Content providers组件主要是封装数据操作接口，提供数据最基本的增加、删除、修改、查询操作（一般来讲，访问此类接口需要特定的权限），被操作的数据可以是本地任意格式的数据文件、SQLite数据库文件，还可以是网络文件，Content providers组件主要是实现对数据访问的封装。除了常规的增、删、改、查操作，Content providers还能提供文件读写访问操作，利用openFile接口实现。
Broadcast receivers组件用于响应广播通知，广播可以是来自操作系统发出，也可以是来自第三方任意APP发送。
对于上述四大组件的安全问题，都与组件实现的具体功能紧密相关，测试过程中需要具体问题具体分析，这里主要讨论一下典型通用的问题。
Activities组件安全
该类漏洞的审查场景：Activities组件响应Intent object |
漏洞类型说明：
Activities组件主要用于向用户提供可视化交互界面，Activities组件之间可以通过Intent object交互（同一APP中的不同Activities或者是不同APP中的Activities都可以交互，只要具备相应的访问权限）。如下：
如果APP中Activities组件的访问控制权限设置不当，任意第三方APP可以通过构造特定的Intent object，启动APP中特定的Activities组件，执行特定的操作。比如：
http://wooyun.org/bugs/wooyun-2010-057970
http://wooyun.org/bugs/wooyun-2010-048502
审核点及方法：对于只用在APP内部交互的Activities组件，在AndroidManifest.xml配置中务必确保其exported属性为false，禁止随意开放Activities组件的访问权限，对于需要和外部进行交互的Activities组件，应当添加适当的访问权限控制，同时组件在处理Intent object中的数据之前，必须对数据的有效性和合法性进行校验。
Services组件安全
该类漏洞的审查场景：Services组件响应Intent object |
漏洞类型说明：
Services组件运行于系统后台，执行长时间操作或者远程进程工作，不提供用户交互界面。Services组件可以响应Intent object，执行相关的操作。
Services组件响应Intent object的交互类似于Activities组件响应Intent object的交互，只不过发送Intent object的方法换成startService()或者bindService()。若APP中Services组件访问控制权限设置不当，任意第三方APP可以通过构造特定Intent object，调用APP中特定的Services组件执行特定操作，比如：
http://www.wooyun.org/bugs/wooyun-2010-048025
审核点及方法:对于只用在APP内部交互的services组件，在AndroidManifest.xml配置中务必确保其exported属性为false，禁止随意开放services组件的访问权限，对于需要和外部进行交互的services组件，应当添加适当的访问权限控制，同时组件在处理Intent object中的数据之前，必须对数据的有效性和合法性进行校验。
Content providers组件安全
该类漏洞的审查场景：通过ContentResolver调用ContentProvider数据操作接口 |
漏洞类型说明：
Content providers组件封装数据操作，提供典型的数据交互操作接口，包括数据添加、删除、修改、查询接口，同时还提供通过openFile方法操作文件。
当APP对Content providers的访问控制权限设置不当时，将导致任意第三方APP通过Content URIs访问ContentProvider的接口，操作敏感数据。
https://intrepidusgroup.com/insight/2011/08/dropbox-for-android-vulnerability-breakdown/
http://www.wooyun.org/bugs/wooyun-2010-047098
审核点及方法：通常来说，Content providers组件基本上都是用于APP内部数据操作，应禁止外部第三方APP对Content providers组件接口的调用，在AndroidManifest.xml配置中必须确保其exported属性为false，对于少数需要提供给外部访问的Content providers组件，务必添加适当的访问权限控制，Content providers组件的实现中应该判断调用者的packageName或者pid，确保调用者是符合预期，而不是任意的第三方APP，同时还需要对查询参数的合法性、有效性进行验证。
Broadcast receivers组件安全
该类漏洞的审查场景：响应系统或者第三方APP发送的广播 |
漏洞类型说明：
Broadcast receivers组件用于响应系统或者第三方APP发送的广播，APP中的Broadcast receivers可以接受特定的广播信息，执行特定的操作。
广播信息以Intent object作为载体，Broadcast receivers组件响应Intent object的交互类似于Activities组件响应Intent object的交互，只不过发送Intent object的方法换成sendBroadcast()。Broadcast receivers组件接受到广播数据后，根据广播信息，执行特定的操作。若APP中Broadcast receivers组件访问控制权限设置不当，任意第三方APP可以通过构造特定Intent object，触发APP中特定Broadcast receivers组件执行特定操作，比如：
http://wooyun.org/bugs/wooyun-2010-041514
http://wooyun.org/bugs/wooyun-2010-0511
审核点及方法：对于只用在APP内部交互的Broadcast receivers组件，在AndroidManifest.xml配置中务必确保其exported属性为false，禁止随意开放Broadcast receivers组件的访问权限，对于需要和外部进行交互的Broadcast receivers组件，应当添加适当的访问权限控制，同时组件在处理Intent object中的数据之前，必须对数据的有效性和合法性进行校验。
动态注册Receivers组件安全
该类漏洞的审查场景：动态注册的Receiver响应系统或者第三方APP发送的广播 |
漏洞类型说明：
通过Context.registerReceiver动态注册的Receiver，也可以响应第三方APP发送的广播,而无需在AndroidManifest.xml中静态声明。因此在考察Broadcast receiver组件的安全时，也需要考虑这类动态注册的receivers。
可以通过registerReceiver (BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheduler)并在boradcastPermission中声明发送者必须拥有的权限，如果这个权限为null或者调用的是registerReceiver (BroadcastReceiver receiver, IntentFilter filter)，则代表任意第三方APP都可以向receiver发送这个广播。
审核点及方法：检查代码中通过registerReceiver注册的Receiver，注意调用时是否声明发送者的权限，可能需将该Receiver视为等同于导出的Receiver，并对数据的有效性与合法性进行校验。
组件安全总结
针对APP中的四大组件安全：Activities组件安全、Services组件安全、Content providers组件安全、Broadcast receivers组件安全。安全问题实际上和组件实现的具体功能密切相关，文档中仅能就同一的部分进行概括描述，在实际的评估测试过程中，应当根据APP各组件的具体功能，具体分析。
通用原则：① 如果组件仅用于APP内部交互，在AndroidManifest.xml配置中务必确保其exported属性设置为false，禁止导出；② 若组件需要开放给外部APP调用，则必须添加适当的访问权限控制；③ 对接受到的数据，组件在对数据进行处理之前必须对数据进行合法性和有效性验证，避免通过畸形数据的注入，导致程序执行流程被操控，或者直接导致APP奔溃。
输入校验
传统的应用安全中很重要的一部分是输入校验。Android APP主要通过组件导出来接收外部Intent中的数据。在"组件安全"章节中描述了如何识别这些导出的组件，并要求对数据有效性与合法性进行验证，本节进一步描述输入校验不当可能出现的安全问题。
SQL注入
该类漏洞的审查场景：数据库操作接口接受来自外部的输入 |
漏洞类型说明：
Android利用SQLite保存数据。与传统的数据库操作应用相似，Android APP也可能存在SQL注入漏洞，可导致敏感数据泄露或篡改。因此当数据库操作接口接受来自外部的输入时，应当始终对输入的数据进行校验。
SQL注入示范1：execSQL传入拼接的SQL语句
String sql = "DELETE FROM case_values WHERE _id = " + paramString;
localSQLiteDatabase.execSQL(sql);
SQL注入示范2：ContentProvider中，如果未检查外部传入的projection, selection就直接调用SQLiteDatabase.query方法，该方法内部会拼接projection，selection构造SQL语句，导致SQL注入。
public class MyProvider extends ContentProvider{
…
public Cursor query(Uri uri, String[] projection, String selection,
String[] selectionArgs, String sortOrder) {
SQLiteDatabase localSQLiteDatabase = xx.getReadableDatabase();
localSQLiteDatabase.query(TABLENAME, projection, selection, selectionArgs, null, null, null);
…
审核点及方法：
黑盒审查方法：特别注意所有导出的Content Provider，可结合工具（Mercury, Drozer）检查SQL注入漏洞。
白盒审查方法：检查代码中调用数据库查询的点，特别注意调用SQLiteDatabase的execSQL，query，queryWithFactory，rawQuery，rawQueryWithFactory，delete，update等方法，其字符串参数例如sql, table, whereClause, columns, selection, groupBy, having, orderBy, limit参数都被用于拼接构造SQL语句，因此如果这些参数来自不信任的输入，又未进行充分校验，就可能导致SQL注入。
路径遍历
该类漏洞的审查场景：文件操作接口接受来自外部的输入 |
漏洞类型说明：
在"存储安全"章节已经叙述了Android对APP读写文件有权限控制。但在某些场景下， APP接受外部输入后不进行校验就直接拼接构造文件路径，并进行文件操作，也可能APP私有的文件被读写。
路径遍历示范1：在APP中，来自外部的未经检查的字符串filename被传递给openFileOutput方法，并作为文件路径参数。这可能导致攻击者任意覆盖APP的私有文件
file = openFileOutput(filename, Context.MODE_WORLD_READABLE);
路径遍历示范2：ContentProvider中，外部传入的uri未经过任何检查就用于构造文件路径，可能导致攻击者利用类似content://authority/../../file的uri来读取APP私有文件
public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException {
File file = new File(getContext().getExternalFilesDir(null), uri.getPath());
return ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY);
}
审核点及方法：
白盒审查方法：检查代码中进行文件操作的点，注意检查其文件路径是否由外部数据拼接构成，是否对其进行了安全检查或规范化处理。
IPC空引用异常DOS
该类漏洞的审查场景：从Intent中读取数据时未检查是否为Null，也未捕获空引用异常 |
漏洞类型说明：
当空引用异常时，如果APP没有捕获异常，Android通常会结束APP运行。当从外部发送的Intent中读取数据时，如果未检查是否为null也没有捕获异常，攻击者就可能发送特定字段为null的Intent来使得APP停止服务。
审核点及方法：
黑盒审核方法：通过向导出的组件发送简单的Intent，观察APP是否退出。
白盒审查方法：检查代码中处理外部Intent的代码，注意是否对输入数据进行合法检查，或者是否捕获了异常。
Intent注入
该类漏洞的审查场景：APP发送的intent中关键数据来自未检查的外部输入 |
漏洞类型说明：
Android APP内部经常通过发送Intent来调用其他组件或传递数据。APP发送的Intent，可以不受exported=false的限制发送给非导出的组件。此外，如果APP具有特定的权限，也可以发送特定的Intent来调用系统的服务（例如打电话）。
因此，APP在构造将要发送的Intent时，需要严格校验构成Intent的数据是否合法。如果这些关键数据来自不可信的外部输入，可能导致攻击者篡改甚至完全控制Intent。
Intent注入场景1：构造Intent时往往通过这些方法来设定其属性：addCategory(), setAction(), setClass(), setClassName(), setComponent(), setData() 以及setDataAndType()。如果这些属性可被外部控制，那么攻击者可能可以控制该Intent发送的目标。例如某个非导出组件存在空引用DOS漏洞，而攻击者可以通过setAction来控制APP内部发送Intent的Action，那么攻击者就可能通过控制Action使得该Intent发送至存在缺陷的组件。
Intent注入场景2：如果APP调用了Intent.parseUri（String uri, int flags）方法来生成并发送一个Intent，并且其中的uri来自不可信的外部输入，那么攻击者就可能完全控制该Intent，本质上等同于外部攻击者可以以APP的身份发送任意的Intent。
审核点及方法：重点检查APP中构造并发送Intent时，使用的addCategory(), setAction(), setClass(), setClassName(), setComponent(), setData() 以及setDataAndType()这些方法，以及需要特别关注的parseUri()方法，检查这些方法的输入是否可被外界控制且未经过任何安全检查。
WebView组件安全
WebView组件基于WebKit的渲染引擎，用于渲染并展现Web页面，默认设置是不解析执行JavaScript脚本的，不会引人XSS漏洞，也不会导致命令执行。如果APP的功能不需要用到JavaScript脚本，那么务必保持默认配置，切勿调用setJavaScriptEnabled (true)方法。
addJavaScriptInterface命令执行
该类漏洞的审查场景：调用addJavaScriptInterface方法将特定Java对象嵌入到WebView |
问题类型说明：
WebView中的addJavaScriptInterface()方法可以将Java对象嵌入到WebView组件中，嵌入对象可在JavaScript上下文中调用执行。如能控制传入到WebView组件中loadUrl()方法或者loadDataWithBaseURL()方法中的参数，攻击者就可以通过注入恶意JavaScript脚本，进而调用addJavaScriptInterface()方法引人的Java对象，执行任意系统命令。
审核点及方法：针对addJavaScriptInterface()方法导致命令执行的问题，如果APP无需JS交互，应当关闭JavaScript执行，且删除所有的addJavaScriptInterface()方法调用，如果APP需要addJavaScriptInterface()调用，则应当确保输入到loadUrl()、loadDataWithBaseURL()方法的参数可信。对于黑盒检测，可以利用APP打开测试页面http://bitkiller.duapp.com/jsobj.html查看检测结果。
JS本地文件窃取漏洞
该类漏洞的审查场景：loadUrl方法、loadDataWithBaseURL方法输入参数可控 |
问题类型说明：
通过WebView组件loadUrl()、loadDataWithBaseURL()方法加载解析Web页面的时候，如果调用方法中使用的参数值（对loadUrl方法来说是String url参数，对loadDataWithBaseURL方法来说是String baseUrl参数和String data参数）来自用户输入，且使用前未进行有效验证，将导致本地文件读取以及在任意指定域下执行JavaScript脚本的漏洞。
- 场景：获取webviewCookiesChromium.db数据
WebView组件中的Cookies信息默认被保存到/data/data/
审核点及方法：确认APP对应的databases/webviewCookiesChromium.db文件是否包含敏感信息，确认WebView组件对文件MIME类型的解析，确认输入到loadUrl方法中的参数值可信。
- 场景：利用符号链接绕过同源性策略获取数据
WebView本地域执行JavaScript脚本受限于同源性策略的限制，A文件中的JavaScript脚本不允许访问B文件的内容，利用符号链接文件可以绕过同源性策略的限制，利用A文件中包含的JavaScript脚本，获取B文件中包含的数据，详细分析可以参考《Android百度浏览器信息泄露 — 任意私有文件窃取》。
审核点及方法：验证符号链接对同源性策略对影响，确认输入到loadUrl方法中的参数值可信。
- 场景：loadDataWithBaseURL在任意域执行JavaScript脚本
loadDataWithBaseURL方法在String baseUrl参数指定的域下执行String data指定的脚本内容，当baseUrl参数和data参数值被用户控制的情况下，黑客可以在指定的任意域下执行任意指定的JavaScript脚本，可参考《新浪微博APP任意数据窃取漏洞（Android版）》。
审核点及方法：查找APP中所有loadDataWithBaseURL方法的调用，确保loadDataWithBaseURL方法中的参数值可信。