【论文阅读】Tabbed Out: Subverting the Android Custom Tab Security Model

论文链接：Tabbed Out: Subverting the Android Custom Tab Security Model | IEEE Conference Publication | IEEE Xplore

总览

“Tabbed Out: Subverting the Android Custom Tab Security Model” 由 Philipp Beer 等人撰写，发表于 2024 年 IEEE Symposium on Security and Privacy。论文对 Android 的 Custom Tab（CT）组件进行了首次系统安全评估，揭示了其安全模型在设计时未考虑的跨上下文状态推断攻击等问题，并提出了缓解策略。通过与Google的合作，这些漏洞已经得到了修复，但该研究仍然对移动Web桥接技术的安全性具有重要意义，为未来的研究提供了有价值的参考。

研究背景

移动到 Web 的桥梁组件

移动操作系统为开发者提供了多种在原生应用中显示网页的方式。其中，Custom Tab（CT）组件是一种较新的方式，它与底层浏览器共享状态，并能让宿主应用了解网页导航情况。

CT 组件的特性

• 状态共享：与 WebView 等组件不同，CTs 与底层浏览器（如 Chrome、Edge、Brave 和 Firefox 等）共享状态，包括 cookies 和权限。这意味着用户在浏览器中登录网站后，在 CT 中也会被自动认证。

• 导航回调：CTs 支持多种类型的回调，如导航回调（在网页导航事件中触发）和特定于浏览器实现的额外回调。开发者可以通过重写 CustomTabsCallback 类在宿主应用中接收和利用这些事件。

• UI 定制和其他特性：CTs 允许开发者定制浏览器活动的样式，包括修改 URL 栏的颜色、应用进出动画以及在浏览器导航栏中添加自定义操作。此外，CTs 还提供了一些性能优化，如预初始化浏览器和预加载可能访问的网页。

CT 的使用情况

• 数据集：从 AndroZoo 获取应用列表，筛选出在 Google Play 商店中可用且安装量超过 1M 的应用，最终得到 50,831 个应用作为数据集。

• 评估方法

  • CT 使用检测：使用 Androguard 静态分析框架，搜索特定字符串和函数的使用情况，以确定应用是否使用 CTs 以及使用的位置。

  • 库的特征分析：根据检测到的 CT 使用情况，对相关库进行分组和分析，通过查看文档、开源代码和示例应用来了解库如何使用 CTs。

• 实验结果

  • CT 使用情况：在数据集中，83% 的应用（42,372 个 APKs）使用了 CTs。其中，55% 的应用可以识别到对 CT 支持库的 launchUrl 函数的调用，26% 的应用使用了回调。

  • CT 使用模式：CTs 主要用于两个目的：显示应用上下文之外的 Web 内容和与外部服务进行认证。不同的库使用 CTs 的方式有所不同，例如广告相关的库使用 CTs 跟踪广告交互，认证相关的库使用 CTs 进行用户认证。

研究动机

尽管 CT 组件提供了良好的用户体验，但它的安全模型可能存在漏洞。之前对 Android WebView 组件的研究已经揭示了许多安全风险，而 CT 组件作为一种类似但具有不同特性的组件，其安全性尚未得到充分研究。

攻击&防御

1. CT 活动隐藏攻击

概念：攻击者通过利用 CT 回调机制，将 CT 活动隐藏在后台，使其不被用户察觉。

原理：当 CT 被打开时，会触发 TAB_SHOWN 事件。攻击者让启动 CT 的活动监听此事件，并在收到事件后立即启动另一个活动，将 CT 活动覆盖。同时，通过重写覆盖活动的 onBackPressed 函数，防止用户通过返回按钮显示 CT。

具体步骤：

攻击者隐藏 CT 活动主要通过以下两种方式：

CT 活动隐藏（利用回调机制）

• 步骤一：启动 CT 并监听事件

  • 攻击者让潜在有害应用（PUA）中的某个活动（如 Activity A）通过 launchUrl 方法启动 CT 并打开目标网站。

  • CT 在启动过程中会触发一系列事件，其中当 CT 变得可见时会触发 TAB_SHOWN 事件。Activity A 会监听此事件。

• 步骤二：启动覆盖活动

  • 当 Activity A 接收到 TAB_SHOWN 事件后，立即启动另一个活动（如 Activity B）。此时，即使 Activity B 处于前台，未来的 CT 回调事件仍然会报告给 Activity A，从而在视觉上隐藏了 CT 活动。

• 步骤三：处理活动栈相关操作

  • 当用户按下返回按钮或进行返回手势时，活动栈会按照打开的顺序进行操作。通常情况下，栈顶的活动会被移除，CT 会显示出来。为了防止这种情况，攻击者可以在覆盖活动（Activity B）中重写 onBackPressed 函数。通过这样做，当用户执行返回操作时，不是显示 CT，而是重新启动之前的 Activity A，从而保持 CT 的隐藏状态。

利用同活动覆盖（适用于特定场景）

• 操作方法

  • 攻击者可以让启动 CT 的同一个活动（如 Activity A）覆盖 CT。例如在视频播放场景中，当用户在 Activity A 中观看视频时，启动 CT 后，Activity A 立即覆盖 CT，提供给用户不间断的视频体验。同时，在启动多个 CT 的情况下，可以按照顺序依次启动 CT，每个 CT 由前一个 CT 的 TAB_SHOWN 事件触发，最后在所有 CT 都打开后启动覆盖活动，实现多个 CT 的隐藏。

• 注意事项

  • 在这种方式下，需要注意 UI 可能会在 CT 启动过程中出现短暂的无响应情况。例如在视频播放场景中，视频播放期间，UI 控件在 CT 启动时会有一小段时间无响应。

实验数据：在 Google Pixel 6a 运行 Android 13 和 Chrome 112 上进行测试，打开单个 CT 平均使 UI 无响应 0.2s，打开 10 个并行 CT 约 1.7s。

防御方法：可以通过检测应用是否存在异常的活动启动和切换行为来防范。同时，系统可以限制应用对活动栈的过度操作权限。

2. 网页内容隐藏攻击

概念：

攻击者利用 CT 的底部栏和一些特性，隐藏网页内容，改变导航栏信息，以达到隐蔽攻击的目的。

原理：尽管底部栏高度有限，但嵌入较大元素可隐藏内容，并创建与网站背景颜色相同的覆盖层。还可通过一些方法改变导航栏信息，如隐藏按钮、改变颜色等。

防御方法：可以限制底部栏的自定义程度，防止嵌入过大元素。同时，对导航栏的设置进行监控，防止异常的信息改变。

3. Cross-Context State Inference（跨上下文状态推断）

概念： 跨上下文状态推断攻击利用Custom Tab组件与底层浏览器共享状态（如cookies和权限）的特性，允许攻击者推断出用户的敏感信息。

原理： 当用户在浏览器中登录某个网站时，他们在Custom Tab中也会隐式地被认证。攻击者通过利用Custom Tab的回调机制（如导航事件回调），可以捕捉到用户与网站的交互信息，从而推断出用户的登录状态、浏览历史等敏感信息。

相关说明： 文章描述了实验方法和攻击效果。例如，通过测量资源加载时间，攻击者可以推断出用户在网站上的特定状态，如购物车中的商品数量。

• 实验数据说明

  • 基于状态码的攻击：如 4xx/5xx 状态码且空响应体触发特定导航事件组合可用于推断。

  • 基于重定向的攻击：不同类型的重定向（HTML/JavaScript 或 HTTP）触发不同导航事件，可据此判断用户认证状态等。

  • 基于下载的攻击：在 Chrome、Edge 和 Brave 中，触发下载的资源在 CT 中会触发特定事件，用于推断用户状态。

  • 基于内容类型的攻击：某些媒体类型资源触发特定事件，可在特定条件下推断用户状态。

  • 基于时间的攻击：测量导航开始和结束事件的时间间隔，依据不同用户状态下资源加载时间差异来推断。

防御方法：

• 限制Custom Tab回调的使用，特别是在后台时禁用回调。

• 扩展HTTP请求头中的指令列表，添加用于HTTP请求起源的webview关键字，以区分请求是否来自可信环境。

4. HTTP Header Injection（HTTP头注入）

概念： HTTP头注入攻击允许攻击者向由Custom Tab发起的请求中注入额外的HTTP头。

原理： 由于Custom Tab在处理HTTP请求时未能充分清理或验证HTTP头的值，攻击者可以构造恶意请求，注入自定义的HTTP头，从而绕过安全机制或执行未授权的操作。

防御方法：

• 对HTTP头的值进行严格的清理和验证，确保不包含恶意内容。

• 更新Custom Tab组件以修复已知的安全漏洞。

5. SameSite Cookie Bypass（SameSite Cookie绕过攻击）

概念： SameSite Cookie绕过攻击允许攻击者绕过SameSite属性的限制，将cookie附加到跨站请求中。

原理： SameSite cookie属性用于限制cookie是否应附加到跨站请求中，以防止跨站攻击。然而，Custom Tab在处理SameSite Strict cookie时存在漏洞，允许攻击者绕过这一限制。

防御方法：

• 更新Custom Tab组件以严格遵守SameSite cookie标准。

• 对于需要跨站请求的场景，使用其他安全机制（如CORS）来保护cookie。

6. Scroll Inference（滚动推断攻击）

概念： 滚动推断攻击允许攻击者通过监控用户在Custom Tab中的滚动行为来推断用户的敏感信息。

原理： Custom Tab提供了滚动事件的回调机制，攻击者可以利用这些回调来捕捉用户的滚动行为，并通过分析滚动数据来推断用户的浏览习惯、阅读速度等敏感信息。

防御方法：

• 限制或禁用Custom Tab中的滚动事件回调。

• 使用隐私保护技术来模糊或隐藏用户的滚动行为。

7. Bottom Bar Info Leakage & Phishing（底部栏信息泄露和钓鱼）

概念： 底部栏信息泄露和钓鱼攻击允许攻击者利用Custom Tab中的底部栏来泄露用户信息或执行钓鱼攻击。

原理： Custom Tab中的底部栏可以显示来自Web内容的提示或信息。攻击者可以构造恶意的Web内容，利用底部栏来显示虚假信息或诱骗用户执行敏感操作。

相关说明： 文章指出，攻击者可以利用底部栏来显示虚假的登录提示或支付信息，从而诱骗用户输入敏感信息。

防御方法：

• 对Custom Tab中的底部栏内容进行严格的验证和过滤。

• 提高用户对钓鱼攻击的认识和警惕性。

缓解策略

• 跨攻击缓解

  • CT 嵌入策略：网站运营商可以通过扩展 CSP 和 Fetch Metadata 头部，实现选择退出 CT 加载的机制，防止跨上下文泄漏和钓鱼攻击。

  • 限制状态共享：建议默认在私有浏览上下文中打开网站，或者通过扩展 CT API，在用户明确批准的情况下允许状态共享。在存在信任关系（如通过 Digital Asset Links）时，可以绕过批准对话框。

• 特定攻击缓解

  • 限制导航回调：可以通过减少共享信息的粒度（如将所有完成的导航事件分组为一个）或仅在存在 Digital Asset Link 时允许回调，来缓解跨上下文信息泄漏。

  • 限制背景回调：限制对后台 CT 的回调，因为 CTs 主要用于显示用户交互的内容，隐藏的 CT 接收回调可能是恶意的。

  • 限制滚动回调和额外命令：禁止第三方应用接收滚动事件，可以防止滚动推断攻击。可以通过在存在 DAL 时才启用此功能来保持兼容性。

  • 限制底部栏高度：防止底部栏覆盖页面内容，从而使滚动推断攻击不再隐蔽。

  • 底部栏意图中的 URL 净化：在底部栏点击时发送给应用的 Intent 中删除 URL，可以防止底部栏欺骗攻击。同时，可以对 URL 进行净化，只保留来源信息，以保持一定的兼容性。

  • 省略 SameSite Strict Cookies：在 CT 中加载网站时，不应发送 SameSite Strict Cookies，因为这是跨上下文请求，类似于在浏览器弹出窗口中加载网站。

  • 净化 HTTP 头部值：通过拒绝包含换行符的畸形 CORS - approvelisted HTTP 头部，可以修复头部注入攻击。

案例研究

• 性偏好检测：针对 FetLife 社交网络，攻击者可以利用跨上下文状态推断攻击中的时间向量，通过在 CT 和隐藏的 WebView 中同时打开登录页面，并比较加载时间，来确定用户是否在该网站上有活跃会话，从而推断用户是否属于特定社区。

• ProtonMail 登录检测：攻击者可以利用跨上下文状态推断攻击中的重定向向量，针对 ProtonMail 电子邮件服务，通过在 CT 中打开登录页面，根据收到的 NAVIGATION_FAILED 事件数量来判断用户是否已登录。

• 位置历史泄漏：针对 Google Maps Timeline 服务，攻击者可以通过在 URL 中编码目标日期和位置，并利用 CT 浏览器的滚动功能，结合滚动推断攻击，泄漏用户在特定日期是否访问过特定地点的信息。

• 社交账号匿名化：攻击者可以利用 CT 底部栏和一些社交网络的自动重定向端点，通过在 CT 中加载特定端点，并隐藏视图端口，诱使用户点击底部栏，从而获取用户的社交账号用户名。

• Instagram 钓鱼攻击：攻击者可以利用 CT 底部栏，在 Instagram 上显示一个包含虚假消息的帖子，诱使用户点击底部栏，然后提示用户输入当前密码和新密码，从而窃取用户的凭据。

Q&A

文章分析Custom Tabs使用情况方法的局限性

1. 代码混淆问题可能产生假阴性

• 类和方法重命名

  • 开发者可能会在构建过程中对类和方法进行重命名，这会导致静态分析框架难以识别 CT API 的正确使用情况。例如，原本用于启动 CT 的 launchUrl 函数可能被重命名为其他名称，使得分析工具无法准确检测到应用是否使用了该函数来启动 CT。

• 字符串混淆

  • 字符串也可能被混淆，这对于检测 CT 使用的关键字符串（如 android.support.customtabs.extra.SESSION）造成困难。如果该字符串被加密或替换为其他难以识别的形式，静态分析工具可能无法找到它，从而错误地判断应用没有使用 CT 组件。

2. 死代码问题可能产生假阳性

• 应用可能包含一些在实际运行中从未被使用的代码片段。如果这些代码片段中包含 CT API 的使用，静态分析方法会将应用标记为使用 CT 组件，但实际上这些代码在应用运行过程中并不会执行相关的 CT 操作。这种情况会导致分析结果出现假阳性，即错误地认为应用使用了 CT 组件，而实际上并没有真正的 CT 相关功能被调用。

论文中如何评估 CT 隐藏工具的性能？

论文通过测量用户界面（UI）的响应时间来评估 CT 隐藏工具的性能，具体如下：

CT 活动隐藏工具

• 实验设置

  • 在 Google Pixel 6a 运行 Android 13 和 Chrome 112 的设备上进行测试。

  • 通过多次重复实验来获取较为准确的数据。

• 评估指标

  • 测量从攻击开始（即启动 CT 隐藏操作）到 UI 再次响应所花费的时间。

• 实验结果

  • 打开单个 CT 时，平均使 UI 无响应的时间约为 0.2 秒。

  • 当同时打开 10 个并行 CT 时，UI 无响应的时间约为 1.7 秒。

网页内容隐藏工具

• 相关说明

  • 论文中未提及针对网页内容隐藏工具通过类似 UI 响应时间的方式给出具体性能评估数据，但强调了其在隐藏网页内容方面的有效性及相关原理，如利用底部栏嵌入元素隐藏内容以及改变导航栏信息等操作对攻击隐蔽性的影响。