移动应用的关键攻击面

LiveOverflow 发布了一个关于移动应用安全的有趣视频，他在视频中探讨了移动应用的攻击面，并讲述了一位夸大自己研究成果的安全“研究人员”的案例。

移动应用构建在一个以缩小攻击面为设计理念的环境之上，这一环境采用了沙箱、显式权限模型、自动更新，并提供力求默认安全的 API。

然而，有些移动应用确实暴露了需要特别关注的关键攻击面，其原因可能是它们所基于的技术栈、应用所提供的使用方式，或应用与其他组件之间的交互。 另一个需要考虑的关键因素是，这些环境需要不断增加新的特性和功能。这些特性为开发人员提供了发挥创意、探索手机新用法的空间，但同时也扩大了攻击面。以 iOS App Extension 为例，这一类似于 Android Intent 的功能是后来才加入 iOS 生态系统的。

以下是我们过去见过的几个示例，它们属于安全上的严重漏洞，但又非常特定于移动环境：

基于 JavaScript 的应用中可远程利用的 JavaScript 注入：

使用 Cordova、Ionic 等 JavaScript 框架开发的应用可能存在 JavaScript 或 HTML 注入漏洞。由于这些框架所暴露 API 的特性，这类漏洞可以被进一步利用为远程代码注入。

要使此类漏洞被视为严重漏洞，攻击者必须能够在无需任何特殊交互的情况下，将恶意输入发送给其他用户。

例如，一款运动应用允许用户通过个人主页墙分享自己的进度。如果该主页墙存在 JavaScript 注入（XSS）漏洞，那么任何查看攻击者主页墙的用户都会遭到入侵。

即使是 HTML 注入漏洞，也可能通过 JavaScript Gadget 攻击转化为 JavaScript 注入。

通过不可信输入触发原生代码中的内存破坏：

一些应用使用原生库来解析音频、视频和图像等二进制格式。这些库中可由不可信输入触发的内存破坏漏洞将导致远程代码执行。

例如，如果一个允许发送 MP4 格式语音录音的聊天应用存在内存破坏漏洞，就会导致在该应用上下文中的远程代码执行。

除非使用了不安全的 API，否则 Java、Kotlin、Objective C 和 Swift 都是内存安全的语言，但链接 C 和 C++ 编写的库就为这类漏洞打开了大门。

通过 Chrome 中的路过式攻击利用可浏览 Activity 中的 Intent 注入：

Chrome 允许向具有 Browsable 类别的 Activity 发送带有额外参数的 Intent。如果应用可通过 Intent 的额外参数被注入，就容易遭受路过式（drive-by）利用。

攻击者可以诱使受害者访问其恶意页面，也可以例如通过广告来投放攻击。Firefox 浏览器需要额外的用户交互才能触发 Intent 发送，而移动设备上的大多数其他浏览器则不支持此功能。

通过明文流量通信或使用不安全的 TLS/SSL 服务器证书验证：

此漏洞的影响取决于所交换数据的性质。例如，如果身份验证阶段或任何依赖会话的操作是通过不安全的通道进行的，就会导致用户会话被攻陷。

如果应用使用 JavaScript 框架开发，那么获取远程 JavaScript 或 HTML 将导致远程代码执行。如果应用通过不安全的通道下载共享库（.so、.dex、.jar），同样会导致远程代码执行。

此漏洞的一个示例是使用 ALLOW_ALL_HOSTNAME_VERIFIER：

ALLOW_ALL_HOSTNAME_VERIFIER 的实现不执行任何验证：

移动应用与 Web 应用共享会话管理，且移动后端缺少 Web 相关防护：

Web 应用与其他 Web 应用共享同一个浏览器，这为一系列不适用于移动应用的攻击创造了机会，例如 CSRF、通过各类 XSS 实现的会话劫持，甚至点击劫持。

一般来说，移动应用并不存在这些攻击向量，因此开发人员无需针对这些攻击实施任何安全防护。

然而，有些移动应用的后端确实在 Web 和移动后端之间共享会话管理系统，这就使攻击者有机会从浏览器关联到移动后端并利用这些漏洞。