当前位置：首页 > article >正文

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

article 2024/10/27 11:51:36

论文链接：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 秒。