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/<package_name>目录
审核点及方法:/data/data/<package_name>是Android系统分配给APP的默认私有存储目录,典型结构如下:
/data/data/<package_name>目录中的文件只属于对应的APP,只允许所属APP访问该目录的文件,如果开发者将文件的访问模式设置为Context.MODE_WORLD_READABLE或者Context.MODE_WORLD_WRITEABLE,将导致文件全局可读/写,造成文件可被任意APP访问。如下:
可以看到loginshare.json的访问权限是第三方可读的,这样系统中已安装的任意APP都可以访问到loginshare.json中的内容,导致敏感信息泄露。
黑盒方法:通过adb shell连接Android模拟器或者测试机(要求拥具备root访问权限),进入对应的/data/data/<package_name>目录,查看各个文件的访问权限和存储内容,确保两个方面:1. 无论文件权限如何设置,文件都不能存储高敏感信息,比如密码;2. 所有文件的权限都应当设置为禁止第三方APP读/写。
- 场景:数据存储在外部设备(如: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/<package_name>/databases/ webviewCookiesChromium.db,而WebView组件在解析文件内容的时候,对文件MIME类型缺乏合理的校验,对于SQLite数据库db文件,只要其中包含合法的HTML标签,就会被WebView解析执行,攻击者可以利用Cookie信息向webviewCookiesChromium.db中插入HTML标签,引人JavaScript脚本解析执行,窃取webviewCookiesChromium.db的内容,详细分析可以参考《Android百度浏览器信息泄露 — Cookie数据窃取》。
审核点及方法:确认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方法中的参数值可信。
Android APP安全测试Checklist相关推荐
- Android App专项测试-压力测试篇
小伙伴们大家好,今天主要分享的主题是Android App专项测试.如何进行Android App专项测试压力测试呢?我们主要通过Android平台的一门工具Monkey.在学习本门课程之前,如果你具 ...
- 【APP渗透测试】 Android APP渗透测试技术实施以及工具使用(客户端服务端)
文章目录 前言 一.安全威胁分析 二.主要风险项 三.Android测试思维导图 四.反编译工具 五.Android客户端 漏洞一.Jnaus漏洞 漏洞二.数据备份配置风险漏洞 漏洞三.Activit ...
- Android App 压力测试 monkeyrunner
Android App 压力测试 第一部分 背景 1. 为什么要开展压力测试? 2. 什么时候开展压力测试? 第二部分 理论 1. 手工测试场景 2. 自动测试创建 3. Monkey工具 4. AD ...
- Android APP压力测试(二) 之Monkey信息自动收集脚本
转载-原文地址: http://www.cnblogs.com/findyou/p/3936063.html Android APP压力测试(二) 之Monkey信息自动收集脚本 前言: 本文重点 ...
- Android App压力测试(Monkey和ADB)
压力测试简介 压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分.压力测试的基本思路很简单:不是在常规条件下运行手动或自动测试,而是在计算机数量较少或系统资源匮乏的条件下运行测试.通常 ...
- Android App压力测试
前言:写这篇文章的目的,一是因为不少同学作为Android开发,很少会自己去做压力测试,不了解相关的技术,不知道压力测试是什么.怎么工作的:二是询问过身边的一些测试同学,他们进行压力测试的时候,很多情 ...
- 利用Appium对Android App进行测试
文章目录 前言 一.软件 二.环境配置 1.安装node.js (Appium 1.11以上版本不需要安装此环境) 2.Android虚拟手机和Java环境 3.安装Appium 4.测试项目的创建 ...
- android app crash测试,APP常见崩溃原因和测试方法整理
测试过APP的人都应该发现,app崩溃是一类非常常见的问题,很多时候还是致命性的,这就要求我们测试人员要尽最大可能去找出软件当中的缺陷,减少app崩溃出现的概率,这里我将收集到的关于针对APP崩溃测试 ...
- android app 渗透测试,android app渗透测试方法大全.pdf
Android APP 渗透测试方法大全 by backlion 一.Android APP 渗透测试方法 1.测试环境 SDK : J a JDK , Android SDK. 工具: 7zip, ...
最新文章
- php 腾讯云实时音视频,腾讯云视频 -实时音视频学习日志
- php soap模块的安装
- vim常用命令使用总结
- 精灵沿着正方形路线运动暂停2秒后然后再将自己放大4倍
- python文件处理seek_python文件操作 seek(),tell()
- jquery改变字符串中部分字符的颜色
- [Leetcode][第312题][JAVA][戳气球][动态规划][记忆化搜索]
- 建议收藏!数据中台行业发展概况及展望
- php 输出时间差,php输出时间差
- androidpn的学习研究(八)androidpn 中业务类XmppIoHandler实现分析
- Struts2框架 下载和配置
- 情感分析资源大全(语料、词典、词嵌入、代码)
- 罗永浩宣布春节后回归科技界;2021年年终奖人均水平为2.3万元;消息人士:字节跳动日均进账10.07亿 | EA周报...
- 【JAVA】java获取项目地址或tomcat绝对地址
- vue 微信公众号支付接口_vue项目中使用微信公众号支付的方法有哪些
- 使用robo 3t连接mongodb的方法
- This experimental syntax requires enabling the parser plugin: ‘optionalChaining‘
- 时标网络图怎么画?详解两大画法
- 流文件和媒体文件的不一样( flv和mp4,avi的区别)
- java布道师_我和 Spring 技术布道师的一天