Android静态安全检测

1.allowBackup标志位

问题描述：

AndroidManifest.xml文件中allowBackup属性值被设置为true时（默认为true），用户可通过adb
backup对应用数据备份，导出应用中存储的数据，造成用户数据的泄露。

修复建议

将android:allowBackup标志位设置为false。

2.debuggable标志位

问题描述：

AndroidManifest.xml文件中debuggable属性值被设置为true时（默认为false），该程序可被任意调试，导致APP被恶意攻击者控制。

修复建议

将android:debuggable标志位设置为false。

3.Activity组件暴露 - exported属性

问题描述：

导出的Activity组件可以被第三方APP任意调用，导致敏感信息泄露，并可能受到绕过认证、恶意代码注入等攻击风险
android:exported用来标示，当前Activity是否可以被另一个Application的组件启动，true表示允许被启动，false表示不允许被启动，这个Activity只会被当前Application或者拥有同样user ID的Application的组件调用。如果Activity中没有intent filter标签，exported默认为false,至少有一个filter的话，意味着这个Activity可以被其它应用从外部唤起，这个时候它的默认值是true。
不只有exported这个属性可以指定Activity是否暴露给其它应用，也可以使用permission来限制外部实体唤醒当前Activity，android:permission 指定启动该Activity所需要的权限名称。

修复建议

如果应用的Activity组件不必要导出，或者组件配置了intent filter标签，建议显示设置组件的“android:exported”属性为false

（注：Service组件暴露，Broadcast Receiver组件暴露，Content Provider组件暴露原理类似。）

4.系统组件本地拒绝服务检测- Intent.getXXX()

问题描述：

导出的组件在处理Intent附加数据的时候，没有进行异常捕获，攻击者可通过向应用发送空数据、异常或畸形数据等，导致应用程序崩溃

修复建议

1.不必要导出的组件，建议显示设置组件的“android:exported”属性为false
2.在使用Intent获取附加数据时，使用try catch进行异常捕获和处理，防止抛出异常引发崩溃

5.强制类型转换本地拒绝服务漏洞 - Intent.getXXXExtra()

问题描述：

导出的组件没有对getSerializableExtra()等获取到的数据进行类型判断而进行强制类型转换，从而导致类型转换异常而导致应用崩溃

修复建议

1.不必要导出的组件，建议显示设置组件的“android:exported”属性为false
2.在做强制类型转换时，要先进行类型判断并使用try catch，防止异常数据导致强制转换抛出异常

6.Intent Scheme URL 漏洞 - parseUri方法

问题描述：

如果浏览器支持Intent Scheme Uri语法，如果过滤不当，那么恶意用户可能通过浏览器js代码进行一些恶意行为，比如盗取cookie等。如果使用了Intent.parseUri函数，获取的intent必须严格过滤，intent至少包含addCategory(“android.intent.category.BROWSABLE”)，setComponent(null)，setSelector(null)3个策略

修复建议

// 将 intent scheme URL 转换为 intent 对象
Intent intent = Intent.parseUri(uri);
// 禁止没有 BROWSABLE category 的情况下启动 activity
intent.addCategory("android.intent.category.BROWSABLE");
intent.setComponent(null);
intent.setSelector(null);
// 使用 intent 启动 activity
context.startActivityIfNeeded(intent, -1)

7.Intent隐式调用

问题描述：

隐式intent没有明确指明哪些接收方有权限接收，恶意程序指定action标识后，可以获取intent内容，导致数据泄露，intent劫持，仿冒，钓鱼应用等风险

修复建议

1.建议使用显示调用方式发送Intent
2.使用Intent.setPackage、Intent.setComponent、Intent.setClassName、Intent.setClass、new Intent(context,Receivered.class)中任一种方法明确指定目标接收方，显式调用intent

8.PendingIntent误用风险

问题描述：

使用PendingIntent的时候，如果使用了一个空Intent，会导致恶意用户劫持修改Intent的内容

修复建议

1.禁止使用一个空Intent去构造PendingIntent
2.构造PendingIntent的Intent一定要设置ComponentName或者action

9.SharedPreferences任意读写

api
getSharedPreferences(String name , int mode)
示例：getSharedPreferences(“config” , Context.MODE_PRIVATE)

第一参数：指定Preference文件的名称，使用xml文件存放数据，名称不用带后缀，文件保存在/data/data//shared_prefs/config.xml

第二参数：指定操作模式。有以下几种：

• Context.MODE_PRIVATE = 0 （0x0000）
  默认操作模式，代表该文件是私有数据，只能被应用本身访问，同时写入的内容会覆盖原文件的内容
• Context.APPEND = 32768 (0x8000) 同样代表文件是私有数据，写入的方式是追加内容
• Context.MODE_WORLD_READABLE = 1 (0x0001) 表示当前文件可以被其他应用读取
• Context.MODE_WORLD_WRITEABLE = 2 (0x0002) 表示当前文件可以被其他应用写入
• Context.MODE_WORLD_READABLE +Context.MODE_WORLD_WRITEABLE = 3
  (0x0003) 表示文件可被其他应用读和写

问题描述：

Shared Preferences文件没有使用正确的创建模式，导致可被其他应用访问，并执行读写操作，可能会导致敏感信息的泄漏

修复建议

1.避免使用MODE_WORLD_READABLE和MODE_WORLD_WRITEABLE模式创建Shared Preferences文件
2.避免把密码等敏感数据信息明文存放在Shared Preferences文件中

10.WebView系统隐藏接口漏洞检测

问题描述：

android webview组件包含3个隐藏的系统接口：searchBoxJavaBridge_, accessibilityTraversal以及accessibility，恶意程序可以利用它们实现远程代码执行

修复建议

对于APP开发者，如果使用了WebView，那么使用WebView.removeJavascriptInterface(String name) API，显示的移除searchBoxJavaBridge_、accessibility、accessibilityTraversal这三个接口

11.WebView组件远程代码执行漏洞检测

问题描述：

WebView组件中的addJavascriptInterface方法用于实现本地Java和JavaScript的交互，但是该函数并没有对方法调用进行限制，导致攻击者可以调用任何JAVA类，最终导致JavaScript代码对设备进行任意攻击

修复建议

1.建议不使用addJavascriptInterface接口，对于Android API Level为17或者以上的Android系统，Google规定允许被调用的函数，必须在Java的远程方法上面声明一个@JavascriptInterface注解
2.在使用js2java的bridge时候，需要对每个传入的参数进行验证，避免恶意代码的攻击

12.WebView明文存储密码

问题描述：

在使用WebView的过程中忽略了WebView setSavePassword，当用户选择保存在WebView中输入的用户名和密码，则会被明文保存到应用数据目录的databases/webview.db中。如果手机被root就可以获取明文保存的密码，造成用户的个人敏感数据泄露

修复建议

使用WebView.getSettings().setSavePassword(false)来禁止保存密码

13.WebView忽略SSL证书错误检测

问题描述：

Android WebView组件加载网页发生证书认证错误时，会调用WebViewClient类的onReceivedSslError方法，如果该方法实现调用了handler.proceed()来忽略该证书错误，则会受到中间人攻击的威胁，可能导致隐私泄露

修复建议

1. 不调用android.webkit.SslErrorHandler的proceed方法
   2.当发生证书认证错误时，采用默认的处理方法SslErrorHandler.cancel()，停止加载问题页面

13.WebView File域同源策略绕过漏洞

问题描述：

应用程序一旦使用WebView，同时支持File域，并打开了对JavaScript的支持，就能利用JavaScript的延时执行，绕过file协议的同源检查，并能够访问应用程序的私有文件，导致敏感信息泄露

修复建议

1.对于不需要使用File协议的应用，禁用File协议，显式设置webView.getSettings().setAllowFileAccess(false)
2.对于需要使用File协议的应用，禁止File协议调用JavaScript，显式设置webView.getSettings().setJavaScriptEnabled(false)

14.证书弱校验 - X509TrustManager.checkServerTrusted方法

问题描述：

自定义实现的X509TrustManager子类中，未对服务器端证书做验证，默认接受任意服务端证书，会存在安全风险，可能会导致恶意程序利用中间人攻击绕过证书校验

修复建议

利用X509TrustManager子类中的checkServerTrusted函数，校验服务器端证书的合法性

15.AES/DES弱加密 - Cipher.getInstance方法

问题描述：

使用AES/DES/DESede加密算法时，如果使用ECB模式，容易受到攻击风险，造成信息泄露

修复建议

使用AES/DES/DESede加密算法时，应显示指定使用CBC或CFB加密模式

16.Hash算法不安全 - MessageDigest.getInstance方法

问题描述：

使用不安全的 Hash 算法(MD5/SHA-1)加密信息，存在被破解的风险
，攻击者利用核心功能与算法可轻易抓取到客户端的敏感数据，并对
其解密，导致用户的隐私泄露或直接财产损失。

修复建议

建议使用SHA-256等安全性更高的Hash算法

17.密钥硬编码 - SecretKeySpec类

问题描述：

应用程序在加解密时，使用硬编码在程序中的密钥，攻击者通过反编译拿到密钥可以轻易解密APP通信数据

修复建议

密钥加密存储或者经过变形处理后用于加解密运算，切勿硬编码到代码中

18.明文数字证书风险 - .cer文件

问题描述：

明文存储的数字证书如果被篡改，可能会造成客户端与服务端之间的传输数据被截获并解密，造成用户信息泄露

修复建议

对数字证书文件(.cer)进行加密，避免证书文件泄露

19.日志泄漏风险 - System.out.print& System.out.println

问题描述：

使用System.out.print和System.out.println输出打印日志信息，容易泄漏敏感信息

修复建议

建议删除所有使用System.out.print和System.out.println输出打印日志信息的代码

20.logcat可能泄露隐私敏感信息 - Log.v( )& Log.d( )

问题描述：

在APP的开发过程中，为了方便调试，通常会使用log函数输出一些信息，这会让攻击者更加容易了解APP内部结构，方便破解和攻击，甚至有可能直接获取到有价值的隐私敏感信息

修复建议

为了APP的错误采集，异常反馈，必要的日志还是要被输出的，建议使用ProGuard等工具在APP的发行版本(release)中自动删除Log.d()和Log.v()对应的代码

21.系统Root检测 - /system/bin/su & /system/xbin/su

问题描述：

APP在Android设备被Root的环境下，没有进行安全检测并采取保护措施，导致系统安全性大大降低

修复建议

在APP运行的时候，应该对Android设备Root环境进行检测，并提示用户注意潜在的安全漏洞

22.外部存储访问检测

问题描述：

检测 APP 中是否存在外置卡操作行为，如果外置卡上存储敏感信息，
易泄露个人信息，升级包数据被篡改等风险

修复建议

建议不要讲敏感信息存储在SDCard上，防止数据泄露或者被篡改，推荐存储在/data/data/packagename/目录下

23.敏感函数调用风险

问题描述：

APP应用程序中调用了包含敏感行为的函数，包括发送短信、发送地理位置、拨打电话等，可能会导致用户隐私数据泄露等风险

修复建议

开发者审核包含敏感行为的函数调用，确保其使用是必要且限制于授权用户的

24.资源文件泄露风险 - .js文件

问题描述：

泄露的js文件如果被读取，可能会造成功能逻辑泄露，如果被篡改，可能被植入钓鱼页面或恶意代码，造成用户的敏感信息泄露

修复建议

对资源文件(.js)进行加密保护，防止资源文件泄露

25.初始化IvParameterSpec函数错误

问题描述：

使用固定初始化向量，结果密码文本可预测性会高得多，容易受到字典式攻击。iv的作用主要是用于产生密文的第一个 block，以使最终生成的密文产生差异（明文相同的情况下），使密码攻击变得更为困难，除此之外 iv 并无其它用途。因此 iv 通过随机方式产生是一种十分简便、有效的途径。

修复建议

禁止使用常量初始化矢量参数构建IvParameterSpec，建议IV通过随机方式产生

byte[] rand = new byte[16];
SecureRandom r = new SecureRandom();
r.nextBytes(rand);
IvParameterSpec iv = new IvParameterSpec(rand);

26.Zip文件目录遍历漏洞 - ZipEntry.getName方法

问题描述：

使用ZipEntry.getName()解压zip文件，没有对上级目录字符串(…/)进行过滤校验，可能会导致被解压的文件发生目录跳转，解压到其他目录，并且覆盖相应的文件，最终导致任意代码执行

修复建议

解压zip文件时，判断文件名是否有…/特殊字符
对重要的Zip压缩包文件进行数字签名校验，校验通过才进行解压

反例：

BufferedOutputStream dest = null;
try {
        ZipInputStream zis = new ZipInputStream(new BufferedInputStream(new FileInputStream("/Users/yunmogong/Documents/test/test.zip")));
        ZipEntry entry;
        while ((entry = zis.getNextEntry()) != null){
            int count;
            byte data[] = new byte[BUFFER];
            String entryName = entry.getName();
            FileOutputStream fos = new FileOutputStream(entryName);
            //System.out.println("Extracting:" + entry);
            dest = new BufferedOutputStream(fos, BUFFER);
            while ((count=zis.read(data,0,BUFFER)) != -1){
                dest.write(data, 0, count);
            }
            dest.flush();
        }
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        try {
            dest.close();
        } catch (IOException e) {
            e.printStackTrace();
    }
}

如上代码，没有对文件的路径名进行判断直接进行解压，如果路径中包含…/字符串，就会造成目录的遍历问题，一旦遭到中间人攻击替换下载的文件，将会导致某些恶意文件被执行。

27.代码动态加载安全检测 - DexClassLoader & PathClassLoader

DexClassLoader可以加载apk,jar或dex文件
PathClassLoader只能加载已经安装到Android系统中的apk文件

问题描述：

使用DexClassLoader或PathClassLoader动态加载dex文件、apk文件、jar文件时，如果这些文件存储在可被其他应用读写的目录中(比如sdcard)，同时没有对外部加载的文件进行完整性校验，导致应用可能会被恶意代码注入并执行

修复建议

1.将所需要动态加载的文件放置在apk内部，或应用私有目录中
2.如果应用必须要把所加载的文件放置在可被其他应用读写的目录中(比如sdcard)，建议对不可信的加载源进行完整性校验和白名单处理，以保证不被恶意代码注入

28.主机名弱校验 - HostnameVerifier.verify方法

问题描述：

自定义实现的HostnameVerifier子类中，未对主机名做验证，默认接受所有域名，会存在安全风险，可能会导致恶意程序利用中间人攻击绕过主机名校验

修复建议

利用HostnameVerifier子类中的verify函数，校验服务器主机名的合法性

29.HTTPS敏感数据劫持漏洞 - SSLSocketFactory.setHostnameVerifier方法

问题描述：

Android APP 在 HTTPS 通信中，使用 ALLOW_ALL_HOSTNAME_VERIFIER，表示允许和所有的 HOST 建立 SSL 通信，这会存在中间人攻击的风险，最终导致敏感信息可能会被劫持，以及其他形式的攻击。

反例：

SSLSocketFactory sf = new MySSLSocketFactory(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

ALLOW_ALL_HOSTNAME_VERIFIER 关闭 host 验证，允许和所有的 host 建立SSL 通信，BROWSER_COMPATIBLE_HOSTNAME_VERIFIER 和浏览器兼容的验证策略，即通配符能够匹配所有子域名 ，
STRICT_HOSTNAME_VERIFIER 严格匹配模式，hostname 必须匹配第一个 CN 或者任何一个 subject-alts

修复建议

验证策略改成严格模式，即把ALLOW_ALL_HOSTNAME_VERIFIER改成STRICT_HOSTNAME_VERIFIER

30.自定义权限的保护级别 - protectionLevel属性

自定义权限如下所示：

属性
android:name 自定义的权限名称
android:label 对权限的简短描述
android:icon 用来标识权限的图标
android:description 对权限的更加详细的描述
android:permissionGroup 权限所属权限组的名称
android:protectionLevel 权限的保护等级
- normal
属性的默认值，代表低风险权限，只要申请了就可以使用（在AndroidManifest.xml中添加标签），安装时不需要用户确认
- dangerous
高风险权限，安装时需要用户的确认才可使用
- signature
只有当申请权限的应用程序的数字签名与声明此权限的应用程序的数字签名相同时（如果是申请系统权限，则需要与系统签名相同），才能将权限授给它
- signatureOrSystem
签名相同，或者申请权限的应用为系统应用（在system image中），与signature类似，只是增加了rom中自带的app的声明 ，尽量不要使用该选项，因为signature已经适合绝大部分的情况

问题描述：

自定义权限的保护等级(android:protectionLevel属性)设置为normal，或没有显示设置(默认情况也为normal)，可能会导致敏感信息泄露

修复建议

建议将自定义权限的保护级别设置为signature或者signatureOrSystem

31.升级包数据篡改 - getExternalStorageDirectory方法

问题描述：

软件自动更新时下载的升级包文件放到了外存中，该文件可能会被篡改，导致遭受攻击

修复建议

1.不要把升级包文件放到外存，另外升级包下载完成后要对升级包进行校验，以防文件被篡改
2.升级包文件可以放在内部缓存目录getCacheDir下

32.重打包防护检测

问题描述：

应用没有进行安全加壳保护，攻击者可以利用重打包等手段修改程序的代码逻辑及原始内容，同时上传仿冒的APP到第三方应用市场，欺骗用户

修复建议

建议使用相应的应用安全加固方案，提供对dex、so等文件的保护

33.其他

1. META-INF 目录中不能包含如.apk,.odex,.so 等敏感文件，该文件夹没有经过签名，容易被恶意替换。

2. Receiver/Provider 不能在毫无权限控制的情况下，将 android:export 设置为 true。

3. 不要广播敏感信息，只能在本应用使用 LocalBroadcast，避免被别的应用 收到，或者 setPackage 做限制。

4. 不要把敏感信息打印到 log 中。

5. 开放的 activity/service/receiver 等需要对传入的 intent 做合法性校验

6. 不要通过 Msg 传递大的对象，会导致内存问题。

7. Log 的 tag 不能是“”。 日志的 tag 是空字符串没有任何意义，也不利于过滤日志。

参考链接：
https://blog.csdn.net/leeyhCoding/article/details/79455376
https://blog.csdn.net/u013107656/article/category/6257625/1?