您的位置:首页 > 其它

2019年安卓应用的7大漏洞类型

2019-10-12 18:00 337 查看
作者 | Susan
译者 | 王强
编辑 | 张之栋、王文婧
由于 Android 系统的开源特性,在 Android 应用程序中往往存在着一些安全漏洞。本文将列举出本年度7大安全漏洞类型,希望能引起大家在 Android 应用程序安全方面的一些思考。

Android 应用程序漏洞的影响是不容忽视的,因为 Google Play 商店使用了开放格式,而且用户可以绕开所有应用安全性监督机制自行安装应用程序。

Android 操作系统的更新和补丁也是个问题。你不能指望 Android 系统能够及时自我更新,因为除了 Google 的 Pixel 设备以外,所有设备的更新计划都是不一样的。

对众多 Android 移动应用进行的测试表明,大多数情况下,Android 应用程序中最常见的安全漏洞是不安全的数据存储。根据一份报告,与 iOS 相比,Android 应用程序中的漏洞和威胁更为常见。但专家们并没有放大这种差异的影响,他们认为两个平台之间应用程序的安全级别大致相当。

对移动应用程序做全面安全检查时,工作包括搜索客户端和服务端中的漏洞,并检查它们之间的数据传输。

 两大方面 
客户端漏洞

60%的漏洞在客户端。

89%的漏洞无需物理访问即可利用。

56%的漏洞无需管理员权限就可以利用。

不安全的进程间通信(IPC)是一个常见的严重漏洞,攻击者可以利用它远程访问脆弱的移动应用程序中处理的数据。

Android 提供了 Intent 消息对象作为应用程序组件相互通信的一种方式。如果这些消息被广播出去,则已注册了 BroadcastReceiver 实例的恶意软件可能会危及其中的敏感数据。

开发人员应使用 LocalBroadcastManager 发送和接收和第三方应用程序无关的广播消息。

服务端漏洞

服务端组件漏洞既能存在于应用程序代码中,也可以出现在应用程序保护机制中,后者包括双因素身份验证实现中的缺陷。比如我们的专家在一个应用程序中遇到的一个漏洞:如果两个相同的请求紧接着发送到服务器,它们之间的间隔很小,那么一次性密码(OTP)既能通过推送通知发送到用户的设备,还能通过短信发送到绑定的电话号码上。攻击者可以拦截短信消息,并模拟合法用户发起攻击,比如窃取用户的银行存款。

如果一次性密码要发送两次,用不着分别使用通知和短信发送。我们应该使用用户选择的密码传送方式。

服务端组件平均包含五个代码漏洞和一个配置漏洞。配置缺陷包括在错误消息中泄露敏感信息、HTTP 标头中的指纹和 TRACE 可用性等。

排名前 7 位的漏洞类型

前七大漏洞列表排序不分先后。这些漏洞是通过严重性、影响力或普遍性挑选出来的,这些漏洞可能会给组织带来数据丢失、泄漏私人信息或其他容易被黑客利用的问题。以下是排名前 7 位的漏洞,以及如何避免这些漏洞的解决方案:

1. 二进制安全

越狱 /Root 检测失效。Root 或越狱设备会破坏系统上的数据保护和加密方案。当设备被 Root,任何形式的恶意代码都可以在该设备上运行,这可能会大大改变应用程序逻辑的预期行为。数据恢复和取证工具通常也可以在 Root 过的设备上运行。

建议:

为了安全起见,最好不要让应用程序在 Root 或越狱过的设备上运行,或者至少要进行某种形式的 Root/ 越狱检测。检测设备是否受到威胁的机制是一层额外的保护策略和风险缓冲,能更好地防止应用程序中的数据泄露。

2. 传输层安全性不足

应用程序经常未能在需要保护敏感通信时加密网络流量。所有需要身份验证的连接都应该加密,尤其是可从互联网访问的网页更应如此。后端连接也应加密,否则可能会使身份验证或会话令牌暴露给与应用程序主机位于同一网络上的恶意参与者。与通过外部互联网发起的连接相比,这些后端连接被利用的可能性较低。但它们一旦被利用仍然可能导致用户帐户受到损害,甚至会更糟。

建议:

每当传输敏感数据(例如信用卡或健康信息)时都应加密。如果应用程序回退到纯文本或以其他方式被迫退出加密模式,就可能被攻击者利用。

确保应用程序具备定义了机密性和基于完整性的安全传输保证的安全约束,这样才能确保所有数据在传输过程中不会被偷窥或更改。如果 TLS 必须在负载均衡器、Web 应用程序防火墙或其他内联主机处终止,则它应该重新加密传输到目标主机的数据。

3. 授权 / 验证不足

当应用程序未执行足够的授权检查,无法确保用户以与安全策略一致的方式执行功能或访问数据时,就出现了授权 / 验证不足的漏洞。

授权过程应强制用户、服务或应用程序只执行允许的操作。当用户通过网站认证时,并不一定意味着该用户应该具有对所有内容和功能的完全访问权限。

建议:

实施经过验证的授权框架方案,该方案应尽可能使用基于策略的配置文件,而不是硬编码的身份验证 / 授权检查。

4. 证书加密验证失效

证书加密验证失效,指的是应用程序没有验证 SSL/TLS 证书,或者正在使用的 SSL/TLS 证书验证系统无法正确验证可信提供商是否已颁发证书。当证书无法验证或未提供时,应将客户端配置为断开连接。在未正确验证证书的连接上交换的任何数据都可能遭受未经授权的访问或修改。

建议:

确保你的应用程序的证书验证机制可以正确验证证书是否提供,并且能验证证书是否来自可靠来源(例如可靠的证书颁发机构)。或者把 IETF 或 CA/B 论坛批准的最新证书透明标准写进代码里。

5. 暴力枚举用户账户

攻击者可以通过多种方式来确定系统中是否存在某个用户账户。暴力攻击是一种通过自动化过程来尝试大量可能以确定未知值的方法。这种攻击利用了值的熵小于感知水平的事实。

例如,虽然一个 8 字符的字母数字密码可以有 2.8 万亿个可能的值,但是许多人会从一个较小的子集(由常用词和术语组成)中选择他们的密码。

如果在错误提交用户名和 / 或密码时错误消息出现更改,则攻击者可以根据错误消息中的差异找出有效的用户名 / 电子邮件地址。

建议:

用户枚举漏洞通常发生在以下功能中:登录、注册或密码找回。应用程序不应透露用户名是否有效。在各个字段中对有效和无效输入的响应应该完全相同。

例如,正确的回答不应该是“对不起,你的密码无效”,而是说:“对不起,你的用户名或密码不正确。请再试一次。”

6. 会话过期不足

用户退出应用程序后,会话期间使用的标识符应被视为无效。如果服务器未能使会话标识符失效,则其他用户有可能使用这些标识符来模拟该用户,并代表该用户执行操作。

建议:

首先,最佳实践是确保在应用程序中实现注销按钮。其次,当用户单击此按钮时,他们的会话应该被正确禁用。

7. 信息泄漏——应用程序缓存

敏感数据可以通过主应用程序代码或第三方框架从应用程序缓存中泄漏。移动设备还在安全数据存储方面面临独有的挑战:设备很容易丢失或被盗;许多用户没有锁定他们的设备,能够直接访问物理设备的攻击者就可以查看缓存的数据。

建议:

确保敏感数据不会意外地通过缓存泄漏。开发人员可以为 OS、框架和平台创建威胁模型来防止这种情况,用威胁模型检查和验证以下数据的处理方式:URL 缓存、键盘按键缓存、日志记录、复制或粘贴缓存、应用程序背景、浏览器 Cookie 对象、HTML5 数据存储以及发送到服务器或其他应用程序的分析数据等。

英文原文: https://codersera.com/blog/top-7-vulnerabilities-in-android-applications-2019/

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: