应用安全问题沉淀

首先对遇到的安全问题进行归类:


安全问题归类.png

服务交互安全测试

  • 进程间交互安全
    由于Android App之间不能共享内存,为了实现不同进程之间的通信,对应到Android系统中的四种组件即为:Activity,Content provider,Broadcast以及Service。使用没有安全性的进程通信机制可能会导致App的敏感数据泄露

解决办法:
在AndroidManifest. xml中检查Activity的exported属性是否位true,如果为true,则可以被第三方App启动,绕过登录等其他页面,暴露用户敏感数据。
在AndroidManifest. xml中检查Content provider的exported属性是否位true,如果为true,则可以被第三方App调用实现增删改查。
在AndroidManifest. xml中检查Broadcast的exported属性是否位true,如果为true,则可以接受第三方App发送的广播消息。
在AndroidManifest. xml中检查Service的exported属性是否位true,如果为true,则可以被第三方App启动。

  • WebView交互安全
  1. 如果使用了webview,则搜索关键字accessibility、accessibilityTraversal和searchBoxJavaBridge_ 在使用webview之前需要调用removeJavascriptInterface("accessibility"),removeJavascriptInterface("accessibilityTraversal"),removeJavascriptInterface("searchBoxJavaBridge_ ")三个函数,如果任意一个函数没有调用,则存在问题。

  2. 如果使用了webview,则搜索关键字setSavePassword。在使用webview之前需要调用setSavePassword(false)函数,如果没有调用,则存在问题。

  3. 如果使用了webview,那就在源码中搜索OnReceivedSslError关键字。当存在onReceivedSslError函数时,检查其中的处理方法,如果调用的是handle.proceed()则存在错误,直接忽略了ssl的错误。如果调用的是handle.cancle()则没有问题。检测WebView加载的页面在未明确要求下,是否使用了Javascript

  4. 搜索关键字setAllowFileAccess。在使用webview之前需要调用setAllowFileAccess(false)函数,如果没有调用或者设置为true,则可能存在同源策略漏洞,需要进一步判断。
    如果设置了setAllowFileAccess(true),则需要设置setAllowFileAccessFromFileURLs(false)和setAllowUniversalAccessFromFileURLs(false),同时需要访谈开发setAllowFileAccess(true)的目的以及是否存在风险。此函数的目的是为了可以通过webview加载html文件,如果html文件是写死可控的,则也可以认为是安全的,如果html文件是变化的,或者是存储在不安全的区域如SD卡,或者是由服务端返回的,则存在风险,需要进一步判断。(备注:加载html里面的js代码需要setJavaScriptEnable(true),如果为false,则风险也不大,因为仅仅加载静态页面风险较小)。
    如果设置setAllowFileAccess(true),则在webview加载url(loadUrl、loadData、loadDataWithBaseURL)时必须全部采用https协议,避免出现中间人攻击。且建议通过白名单的机制校验url的合法性,避免加载恶意链接导致钓鱼攻击。

  5. 搜索关键字setJavaScriptEnabled。如果此函数的参数是false,则用例pass,如果是true,则继续分析(大部分都是true)(还有可能就是一个应用内有多个使用webview的地方,每个webview配置的也不同,这就需要每个都分析一遍) 全工程搜索JavascriptInterface关键字,查看通过注解标注的函数,这些函数是暴露给js交互的接口,存在风险。如果这些函数执行了一些敏感操作或者传递了一些敏感数据,则需要继续分析(这个漏洞被外部提过不少问题,要重视) 对于暴露的接口,在webview加载url(loadUrl、loadData、loadDataWithBaseURL)时需要有下面三条措施:
    1)采用https协议加载url,避免出现中间人攻击。
    2)建议通过白名单机制校验url的合法性,避免加载恶意链接导致钓鱼攻击
    3)对于不同场景的webview分别配置,避免暴露所有接口(比如这个页面的webview需要暴露很多接口,另外一个页面的不需要暴露这些接口,那第二个页面需要单独配置webview,不与第一个页面使用相同的webview配置)

  6. 全工程搜索shouldOverrideUrlLoading|shouldInterceptRequest关键字 查看是否对参数url进行校验。url校验不能仅仅使用getHost、contains、startsWith、endsWith中的一个方法校验,很容易绕过。要多个结合使用。具体需要访谈开发加载哪些域名的url,然后判断校验方法是否存在绕过的风险。

  7. 检测WebView加载资源的完整性,是否加载被篡改后的恶意资源文件

  8. 检测WebView中使用的协议是否是安全通信协议,是否包含具有潜在风险的程序功能

解决办法:
WebView加载的HTML页面在未明确要求下,禁用Javascript
对WebView加载的外部文件进行校验
采用HTTPS安全通信协议

本地数据安全测试

  • (1)数据创建要求进行用户协议检测、数据采集检测、数据输入检测、数据生成检测;

(2)数据存储要求进行访问控制检测、数据加密检测;

(3)数据处理要求进行用户协议检测、敏感数据使用不当检测;

(4)数据共享要求进行第三方SDK用户协议检测、与第三方SDK数据共享检测;

(5)数据备份要求进行敏感数据备份检测、备份数据加密强度检测;

(6)数据销毁要求进行后台运行检测、敏感数据清除检测。

1.1 数据创建

在数据创建阶段,开发者会通过多种方式获取App中的用户信息,例如用户终端ME号码、M号码、位置、手机号、生物识别等,部分App还会嵌入第三方SDK,还可能在用户未知情的情况下,私自上传用户终端或个人信息到第三方SDK的服务器端。本节主要从用户协议、数据采集、数据输入、数据生成4个维度提出安全要求

1.1.1 用户协议

App安装或者更新后,在用户启动App并开始使用前,一般会有一个用户使用协议,对App的主要功能、信息保密条款、法律声明、信息收集等进行说明。用户协议安全要求主要是Ap要存在用户协议,在协议中声明用户信息的用途以及保护措施。

1.1.2 数据采集

数据采集是指开发者因功能需求需要收集用户手机IMEI、IMSI、版本等信息,但如果过度收集用户个人信息,且对用户个人隐私保护不当,容易造成用户个人信息泄露甚至被任意售卖和传播。数据采集安全要求App申请权限采用最小权限机制,避免过度申请如发送短信、读取短信、读取联系人等敏感权限,在使用敏感权限时要告知用户,让用户自己选择,收集的数据需加密后传输。

1.1.3 数据输入

数据输入是指App客户端与服务器端进行通信信息交互时,App采用登录界面、支付界面等方式获取用户输入的账户、密码、手机号、身份证号等信息。在用户输入期间,如果App对上述信息保护不当,就容易造成用户个人信息泄露。数据输入安全要求主要有以下5个方面口客户端采用自定义的软键盘,避免采用系统自带的软键盘,避免黑客利用 Android系统键盘 Event事件记录机制,造成用户输入信息泄露;

1.2 数据存储

App在终端存储的数据包括账号、密码、订单等用户敏感信息,如果存储不当,就很容易造成信息泄露,所以终端存储文件的访问控制和敏感数据加密处理直接影响着终端数据存储的安全。针对数据存储,我们主要从访问控制和数据加密两个维度提出安全要求。

1.2.1访问控制

访问控制是指App客户端在本地生成的文件是否具有适当的访问权限限制。部分开发者在开发过程中未对本地生成的数据文件,xml文件等设置适当的权限限制,把只限于当前程序访问的文件权限设置为了允许其他App访问,就会造成用户数据泄露。访问控制的安全要求是App本地存储的file、xml、 cache、db等文件,均不允许外部程序访问。

1.2.2 数据加密

华为钦定的安全算法
对称加密算法可以使用:AES256及以上强度,禁止DES,3DES
密钥交换算法建议使用:DH1024,ECDHE NIST-P256
数字签名算法:DSA2048 ECDSA NIST-P256
非对称算法建议使用:RSA2048、ECC192及以上强度;禁止使用RSA1024及以下强度
摘要算法建议使用:SHA256及以上强度,非安全相关场景可以使用SHA1,MD5
身份认证算法建议使用:HMAC-SHA256及以上强度;
数字信封建议使用:PKCS#7  

目前App客户端常用的加密算法有AES、DES、RSA、SHA、MD5、Base64等。整体可以分为对称加密算法、非对称加密算法和数字摘要算法,其中Base64不算加密算法,只是对数据进行编码。各个加密算法的优缺点如下。

(1)对称加密算法
高级加密标准和数据加密标准是常用的对称加密算法,使用密钥加密的块算法。优点是加密速度快、效率高,缺点是加密解密是同一个密钥,密钥泄露的话就不能再保证其安全性。
(2)非对称加密算法
RSA加密是一种非对称加密算法,采用公钥、私钥进行加解密,优点是不可逆,缺点是加密内容有长度限制。
(3)数字摘要算法

MD5加密即消息摘要算法( message-digest algorithm),优点是不可逆、可压缩、不容易修改、容易计算,缺点是存在碰撞破解的风险
SHA加密即安全哈希算法( secure hash algorithm),优点是破解难度高、不可逆,缺点 修改,容易计算,缺点是存在碰撞破解的风险。

用户数据的保护能力直接关系到用户信息的安全,根据测评过程中发现的目前App常用的 是可以通过穷举进行破解。数据存储加密保护方式,对数据加密安全的测评主要涉及以下5个方面:

口App在本地生成的文件(包含xml、file、db、 cache)要求加密后存储;

口如果使用对称加密算法对数据进行加密存储,加密密钥不可明文存储或仅进行简单的加密存储,否则会存在泄露加密密钥、用户数据被破解的风险;

口如果对数据进行加密存储的加密算法需要用到随机数,随机数强度要高,不要使用 Random类来获取随机数;需使用SecureRandom.getInstanceStrong()获取随机数,同时不要给 SecureRandom设置种子,以保证生产随机数的安全性;

口对数据进行加密存储的算法不要过于单一,如果多个过程均采用同一种加密算法,一旦被破解,则会泄露所有数据;需要使用多种加密算法组合,并且对不同的数据采用不同的加密算法,以保证用户数据存储的安全性;

口对数据进行加密存储的算法要使用恰当,配置正确,避免使用不安全的加密算法,如

AES28、RSA2048、SHA-256等加密算法被相关部门通报已不再安全。


另 : 记录下一些独特的问题以及原理

  • AVMP问题:

Android组件暴露攻击原理
我们在使用IDE编写代码的时候,Intelligent Tip会给我们的编码问题作出提示,如下图所示,
[图片上传失败...(image-6e0d52-1604922281116)]
是一个使用了未初始化变量的提示。
在Eclipse这样的IDE中,这是一个错误提示,如果不消除这个错误,连编译都无法完成,也就在一定程度上避免了程序员犯“使用未初始化变量”的错误。

但如果仅仅依赖IDE来防止程序员的错误,肯定是远远不够的。

对应Android组件暴露攻击所发现的漏洞,很多人喜欢把其归类到“未对输入进行有效校验”一类,而实际上,我们也可以认为是“使用了未正确初始化的数据造成的程序异常”。
众所周知,所谓组件暴露,实际上是对外暴露了应用的接口,也就相当于暴露了应用程序的攻击面。
恶意的用户可以通过这个攻击面来注入数据,由于“未对输入进行有效校验”,也就导致“数据没有正确地初始化”,一旦使用了这样的数据,就会产生风险。
以Null Intent为例,一个典型的空Intent的数据格式如下,对象中大多数成员的数据为null:
[图片上传失败...(image-4aaea2-1604922281116)]

一旦我们有使用类似如下的代码,就会触发异常:
String data = intent.getStringExtra("data"); // data=null
Log.d(TAG, "Data length:" + data.length()); //data.length会触发NullPointerException
这就是一个典型数据未正确初始化的问题。
解决方法通常是在使用外部传入的数据前,要进行必要的校验,对数据进行正确的初始化。
以上仅是Null Intent攻击会产生NullPointerException问题的一个例子。实际上,这列攻击能够触发超过50种不同的异常类型 如下图[图片上传失败...(image-952f83-1604922281116)]

你可能感兴趣的:(应用安全问题沉淀)