Android 安全预防及修复

   一 常见安全问题及修复

   借鉴：    https://www.zhihu.com/question/22933619
                  https://blog.csdn.net/lin_xijun/article/details/84708003

1.1 校验或限定不严导致的风险或漏洞

1.1.1 fragmnt 注入 

    风险详情：通过导出的PreferenceActivity的子类，没有正确处理Intent的extra值。 

    危害情况：攻击者可绕过限制访问未授权的界面。

    修复建议：当targetSdk大于等于19时，强制实现了isValidFragment

    方法；小于19时，在PreferenceActivity的子类中都要加入isValidFragment ，两种情况下在isValidFragment方法中进行fragment名的合法性校验。

1.1.2 隐式意图调用 

      风险详情：封装Intent时采用隐式设置，只设定action，未限定具体的接收对象，导致Intent可被其他应用获取并读取其中数据。

      危害情况：Intent隐式调用发送的意图可被第三方劫持，导致内部隐私数据泄露。 

      修复建议：可将隐式调用改为显式调用。

1.2，Android Manifest配置相关的风险或漏洞

1.2.1 四大组件暴露

     Activity，Service, ContentProvider, BroadcastReceiver。

     该组件是否允许其他应用调用

     android:exported=["true" | "false"]

     如果当前Activity为私有组件时，应该不允许外部应用调用，android:exported= “false”

     如果当前Activity为公共组件时，允许外部应用调用，android:exported=”true”，为了安全起见，应该进行权限控制

     建议：正常开发过程中当设置为android:exported= “false”

1.2.2 程序被任意调用

      风险详情：安卓应用apk配置文件Android Manifest.xml中android:debuggable=true，调试开关被打开。

      危害情况：App可以被调试。

      修复建议：把Android Manifest.xml配置文件中调试开关属性关掉，即设置android:Debugable="false"。

1.2.3 程序数据任意备份

       风险详情：安卓应用apk配置文件AndroidManifest.xml中android:allowBackup=true，数据备份开关被打开。 

       危害情况：App应用数据可被备份导出。 

       修复建议：把AndroidManifest.xml配置文件备份开关关掉，即设置android:allowBackup="false"。

    组件暴露：建议使用android:protectionLevel="signature"验证调用来源

1.2.4 intent Scheme URLs 攻击

       风险详情：在AndroidManifast.xml设置Scheme协议之后，可以通过浏览器打开对应的Activity。 

       危害情况：攻击者通过访问浏览器构造Intent语法唤起App相应组件，轻则引起拒绝服务，重则可能演变对App进行越权调用甚至升级为提权漏洞。

       修复建议：App对外部调用过程和传输数据进行安全检查或检验，配置category filter, 添加android.intent.category.BROWSABLE方式规避风险，添加跳转条件。

1.3、Log敏感信息泄露

          Log日志中打印信息级别。

          Log日志中是否打印用户敏感信息，比如：用户名，密码或者用户的相关资料信息。

          Log日志中是否有服务器敏感信息，比如：url，token等。

          合理的使用Log开关，来控制打印级别。

          建议：在项目开发过程中在Application 控制log 开关打开，在项目上线时删除不必要的log日志，并关闭log打印。

1.4 慎重使用开源库

      慎重使用开源库，引用三方开源库可能导致项目的不安全性和稳定性。在引用三方库的时候会由于v4,v7包版本的引用和项目引用的v4,v7库的引用不匹配        导致的不兼容，以及如果项目引用的是v4,v7但是开源库使用的是AndroidX也会导致项目的不兼容，项目的解耦性差。

       建议：如果甲方要求严格可以将开源库下载下来，放到项目中开发人员自己修改，升级AndroidStudio版本开发尽量用AndroidX的库。

1.5 文件目录遍历类漏洞

1.5.1Provider文件目录遍历  

   风险详情：当Provider被导出且覆写了openFile方法时，没有对Content Query Uri进行有效判断或过滤。

   危害情况：攻击者可以利用openFile()接口进行文件目录遍历以达到访问任意可读文件的目的。

   修复建议：一般情况下无需覆写openFile方法，如果必要，对提交的参数进行“../”目录跳转符或其他安全校验。

1.5.2 unzip解压缩漏洞  

    风险详情：解压zip文件，使用getName()获取压缩文件名后未对名称进行校验。

    危害情况：攻击者可构造恶意zip文件，被解压的文件将会进行目录跳转被解压到其他目录，覆盖相应文件导致任意代码执行。

    修复建议：解压文件时，判断文件名是否有../特殊字符、

1.6 WebView组件及与服务器通信相关的风险或漏洞

1.6.1 WebView 存在本地JAVA接口

    风险详情：android的webView组件有一个非常特殊的接口addJavascriptInterface，能实现本地java与js之间交互。

    危害情况：在targetSdkVersion小于17时，攻击者利用addJavascriptInterface这个接口添加的函数，可以远程执行任意代码。 

    修复建议：建议开发者不要使用addJavascriptInterface，使用注入javascript和第三方协

 

1.6.2 WebView 组件远程代码执行（调用getClassLoader）    

     风险详情：使用低于17的targetSDKVersion，并且在Context子类中使用addJavascriptInterface绑定this对象。

     危害情况：通过调用getClassLoader可以绕过google底层对getClass方法的限制。 

     修复建议：targetSDKVersion使用大于17的版本

1.6.3 WebView忽略SSL证书错误

     风险详情：WebView调用onReceivedSslError方法时，直接执行handler.proceed()来忽略该证书错误。

     危害情况：忽略SSL证书错误可能引起中间人攻击。

     修复建议：不要重写onReceivedSslError方法， 或者对于SSL证书错误问题按照业务场景判断，避免造成数据明文传输情况。

1.6.4 Webview 启用访问文件数据

  风险详情：Webview中使用setAllowFileAccess(true)，App可通过webview访问私有目录下的文件数据。  危害情况：在Android中，mWebView.setAllowFileAccess(true)为默认设置。当setAllowFileAccess(true)时，在File域下，可执行任意的JavaScript代码，如   果绕过同源策略能够对私有目录文件进行访问，导致用户隐私泄漏。 

 修复建议：使用WebView.getSettings().setAllowFileAccess(false)来禁止访问私有文件数据

1.6.5 SSL通信服务端检测信任任意证书

    风险详情：自定义SSL x509 TrustManager，重写checkServerTrusted方法，方法内不做任何服务端的证书校验。

    危害情况：黑客可以使用中间人攻击获取加密内容。 

    修复建议：严格判断服务端和客户端证书校验，对于异常事件禁止return 空或者null。

1.6.6 HTTPS关闭主机名验证

    风险详情：构造HttpClient时，设置HostnameVerifier时参数使用ALLOW_ALL_HOSTNAME_VERIFIER或空的HostnameVerifier。 

    危害情况：关闭主机名校验可以导致黑客使用中间人攻击获取加密内容。        

    修复建议：APP在使用SSL时没有对证书的主机名进行校验，信任任意主机名下的合法的证书，导致加密通信可被还原成明文通信，加密传输遭到破坏

   1.6。7 SSL通信客户端检测

1,7 数据安全风险数据存储

1,7.1 SD卡数据被第三方程序访问

 漏洞描述：发现调用getExternalStorageDirectory，存储内容到SD卡可以被任意程序访问，存在安全隐患。

 安全建议：建议存储敏感信息到程序私有目录，并对敏感数据加密

1,7.2全局File可读写漏洞-openFileOutput

风险详情：openFileOutput(String name,int mode)方法创建内部文件时，将文件设置了全局的可读权限MODE_WORLD_READABLE。  危害情况：攻击者恶意读取文件内容，获取敏感信息。 

修复建议：请开发者确认该文件是否存储敏感数据，如存在相关数据，请去掉文件全局可读属性。

1,7.3 全局文件可写

   风险详情：openFileOutput(String name,int mode)方法创建内部文件时，将文件设置了全局的可写权限MODE_WORLD_WRITEABLE。

   危害情况：攻击者恶意写文件内容破坏APP的完整性。 

   修复建议：请开发者确认该文件是否存储敏感数据，如存在相关数据，请去掉文件全局可写属性。

1,7.4 全局文件可读可写

    风险详情：openFileOutput(String name,int mode)方法创建内部文件时，将文件设置了全局的可读写权限。 

    危害情况：攻击者恶意写文件内容或者，破坏APP的完整性，或者是攻击者恶意读取文件内容，获取敏感信息。

    修复建议：请开发者确认该文件是否存储敏感数据，如存在相关数据，请去掉文件全局可写、写属性。

1,7.5 私有文件泄露风险-getSharedPreferences配置文件可读 

  风险详情：使用getSharedPreferences打开文件时第二个参数设置为MODE_WORLD_READABLE。 

  危害情况：文件可以被其他应用读取导致信息泄漏。 

  修复建议：如果必须设置为全局可读模式供其他程序使用，请保证存储的数据非隐私数据或是加密后存储。

1,7.6 配置文件可写

   风险详情：使用getSharedPreferences打开文件时第二个参数设置为MODE_WORLD_WRITEABLE。

   危害情况：文件可以被其他应用写入导致文件内容被篡改，可能导致影响应用程序的正常运行或更严重的问题。

   修复建议：使用getSharedPreferences时第二个参数设置为MODE_PRIVATE即可。

1,7.7 配置文件可读可写

   风险详情：使用getSharedPreferences打开文件时，如将第二个参数置为MODE_WORLD_READABLE 或MODE_WORLD_WRITEABLE。

   危害情况：当前文件可以被其他应用读取和写入，导致信息泄漏、文件内容被篡改，影响应用程序的正常运行或更严重的问题。

   修复建议：使用getSharedPreferences时第二个参数设置为MODE_PRIVATE。禁止使用MODE_WORLD_READABLE | MODE_WORLD_WRITEABLE模式。

1,7.8数据加密明文数字证书漏洞：

 Apk使用的数字证书可被用来校验服务器的合法身份，以及在与服务器进行通信的过程中对传输数据进行加密、解密运算，保证传输数据的保密性、完整性。  明文存储的数字证书如果被篡改，客户端可能连接到假冒的服务端上，导致用户名、密码等信息被窃取；如果明文证书被盗取，可能造成传输数据被截获解密，用户信息泄露，或者伪造客户端向服务器发送请求，篡改服务器中的用户数据或造成服务器响应异常。

1,7.9  AES弱加密

风险详情：在AES加密时，使用“AES/ECB/NoPadding”或“AES/ECB/PKCS5padding”的模式。 

危害情况：ECB是将文件分块后对文件块做同一加密，破解加密只需要针对一个文件块进行解密，降低了破解难度和文件安全性。           修复建议：禁止使用AES加密的ECB模式，显式指定加密算法为：CBC或CFB模式，可带上PKCS5Padding填充。AES密钥长度最少是128位，推荐使用256位。

1,7.10随机数不安全使用

   风险详情：调用SecureRandom类中的setSeed方法。

   危害情况：生成的随机数具有确定性，存在被破解的可能性。

   修复建议：用/dev/urandom或/dev/random来初始化伪随机数生成器。

1,7.11  AES/DES硬编码密钥

   风险详情：使用AES或DES加解密时，密钥采用硬编码在程序中。 

   危害情况：通过反编译获取密钥可以轻易解密APP通信数据。

   修复建议：密钥加密存储或变形后进行加解密运算，不要硬编码到代码中。  数据传输：与上面的重复了，也可以把webview系列的漏洞归入这一小类。

 

1.8 动态类漏洞

1.8.1 DEX文件动态加载

   风险详情：使用DexClassLoader加载外部的apk、jar 或dex文件，当外部文件的来源无法控制时或是被篡改，此时无法保证加载的文件是否安全。

   危害情况：加载恶意的dex文件将会导致任意命令的执行。

   修复建议：加载外部文件前，必须使用校验签名或MD5等方式确认外部文件的安全性。

1.8.2 动态注册广播

风险详情：使用registerReceiver动态注册的广播在组件的生命周期里是默认导出的。 

危害情况：导出的广播可以导致拒绝服务、数据泄漏或是越权调用

修复建议：使用带权限检验的registerReceiver API进行动态广播的注册。

 

二 预防提高安全性方案

1. 混淆。

系统提供有proguard文件来将我们要定义的混淆规则定义在里面。被混淆过的项目通过反编译工具，如ApkTool ，dex2jar ， jd-gui等编译出来后，一些代码是显示为a,b,c这样的形式，无法知道具体的类名或者其他。虽然混淆不能保证安全多少。但是，至少能够增强反编译的难度。再说了没有什么事百分之百的，我们所做的安全防护，都只是让攻击者不能这么轻易的就破解而已。

1. 第三方加固工具

现在市场上用的比较多的第三方工具有阿里聚安全，腾讯云应用加固，360加固保，梆梆加固，爱加密第三方加固工具相当于在在我们自己的应用上加了一层壳，让攻击者没有这么简单的拿到我们的数据

第三方加固的原理

我们拿到需要加密的Apk和自己的壳程序Apk，然后用加密算法对源Apk进行加密在将壳Apk进行合并得到新的Dex文件，最后替换壳程序中的dex文件即可，得到新的Apk,那么这个新的Apk我们也叫作脱壳程序Apk.他已经不是一个完整意义上的Apk程序了，他的主要工作是：负责解密源Apk.然后加载Apk,让其正常运行起来。

 

主要步骤：我们拿到需要加密的apk和自己的壳apk，然后用加密算法对源apk进行加密在壳apk进行合并得到新的dex文件，最后替换壳程序中的dex文件就可以了。得到新的apk，这个新的apk主要工作是：负责解密源apk，然后加载apk，让其正常的运行起来。

 

3.加固工具的对比：

体积（体积小的为优）：360 > 腾讯 > 爱加密 > 阿里 > 梆梆

兼容性： 阿里 > 腾讯 > 360 = 梆梆 > 爱加密

启动速度（时间短为优）： 阿里 > 爱加密 > 360 = 梆梆 > 腾讯

漏洞： 腾讯 > 爱加密 > 360 > 梆梆 > 阿里