apk-interceptor

Android 深层链接、Intent 和 WebView 桥接评估辅助工具

apk-interceptor 是一个专为授权应用安全评估而设计的便携式 Android 测试 APK。它帮助安全工程师验证 Android 应用如何处理外部入口点，例如自定义 URI 方案、深层链接、导出的 Activity 和 WebView JavaScript 桥接。

该工具有意受限：

• 它不声明 android.permission.INTERNET
• 它不向外部服务器发送数据
• 它不执行 Shell 命令
• 它不需要 root、Magisk、Frida 或运行时插桩
• 它只提供一个本地 content:// 载荷文件
• 它注册一个在构建时固定的自定义 URI 方案

动机

在 Android 应用安全评估过程中，静态分析得出的许多发现仍需要在设备上制作一个小型概念验证后才能确认：注册一个自定义 URI 方案、发送一个显式 Intent、提供一个本地 content:// 载荷，或者检查 JavaScript 是否能访问 WebView 桥接。

为每种情况构建一个新的临时测试应用既重复又容易出错。清单条目、权限标识符、URI 授权、包名或 Intent 构造上的微小差异都会拖慢验证速度，并使结果更难复现。

apk-interceptor 的创建就是为了使确认步骤可重复。你不必为每次评估编写一个新的 PoC APK，而是使用所需的授权方案或应用 ID 构建此工具，在设备上运行测试，并通过设计保持工作流程受限：无 INTERNET 权限，无外部数据传输，无 Shell 执行，无 root 依赖。

你能测试什么

apk-interceptor 可用于以下评估任务：

详细的漏洞演练：

• 自定义 URI 方案劫持
• 深层链接开放重定向
• 导出 Activity 与不可信 Intent 数据
• 通过 content:// 暴露 WebView JavaScript 桥接

该应用会为发送的 Intent、接收的深层链接、桥接回调、JavaScript 结果和错误维护一个内存评估日志。当应用进程被杀死时，日志会消失。由于日志不会持久化，请在工作时通过截图或屏幕录制来捕获证据。

对比

apk-interceptor 是一个确认工具，而不是发现或利用框架。它假设你已经通过静态分析知道要测试什么（方案、Activity 类、桥接名称），并为你提供一种安全、在设备上的方式来验证可达性并捕获证据。它设计为可安装在评估设备上，甚至可以与客户共享，因此它不包含 INTERNET 权限、Shell 执行、数据泄露或 root 要求。

它与常见 Android 工具集的定位对比：

apk-interceptor 相比其他方案具有最明显优势的两个领域：

• 方案劫持证据：作为实际注册该方案的第二个应用，并记录接收到的每个参数，这是 adb/静态分析无法展示的。
• content:// → WebView 桥接验证：一个非导出的单文件提供程序，其载荷仅通过临时 Intent 读取授权传递，外加一个本地自测 WebView，用于先验证载荷语法。

发送与拦截

apk-interceptor 对发送和拦截的处理不同，这是使用前需要理解的最重要的一点：

要发送一个精心构造的深层链接到被评估应用，你不需要重新构建：使用发送器标签页的隐式深层链接模式并输入任意 URI。

要拦截一个深层链接，即让 Android 将自定义方案路由到 apk-interceptor，以便你可以观察可能的方案劫持，你必须通过 --scheme 使用该方案构建 APK。方案在构建时被有意固定（一个设计护栏）；apk-interceptor 永远不会在运行时注册任意方案。如果你更改了正在评估的方案，请重新构建并重新安装。

要求

• 装有 Android SDK 35 的 Android Studio
• Android 12+ 设备或模拟器
• JDK 17+
• 用于设备安装和可选命令行测试的 adb

构建和安装

使用你被授权评估的自定义 URI 方案构建 APK：

./build-interceptor.sh --scheme <authorized_custom_scheme>
adb install ./out/apk-interceptor-<authorized_custom_scheme>-debug.apk

可选的构建标志：

./build-interceptor.sh \
  --scheme <authorized_custom_scheme> \
  --app-id <custom.application.id> \
  --output ./out

--app-id 在构建时设置安装的应用 ID（设备上的包标识和 content://<applicationId>.payload 授权）。默认值为 com.sterrasec.apkinterceptor。当你需要为不同评估创建多个可单独安装的构建时，使用 --app-id 覆盖。Windows 等效项是 build-interceptor.bat。

默认方案 intercept-poc-example 是一个无害的占位符。构建脚本拒绝使用该默认方案生成评估 APK。

首次启动

在首次启动每个应用版本时，apk-interceptor 会显示一个授权使用对话框。在你点击我理解后，同一版本将不再显示该对话框。 发送器标签页仍然会显示一个持久警告，因为它可以向其他应用发送 Intent。

屏幕截图

发送器	载荷	拦截器

应用模块

拦截器

使用此标签页验证自定义 URI 方案的拦截。

它显示的内容：

• 编译到此 APK 中的方案
• 如果假默认方案仍在使用，则显示警告
• 接收到的深层链接日志
• 一个测试查询参数字段
• 发送测试深层链接
• 清除

基本工作流程：

1. 使用被评估的自定义方案构建 APK。
2. 将其与被评估的应用一起安装。
3. 从被评估的流程、浏览器、adb 或内置的发送测试深层链接按钮触发该方案的深层链接。
4. 如果 Android 将链接路由到 apk-interceptor，打开拦截器标签页并检查接收到的 URI 和查询参数。

关于发送测试深层链接：它总是发送 <scheme>://test?<your params>，使用固定的 test 主机，因此它旨在确认 apk-interceptor 接收并记录该方案，而不是驱动被评估应用的特定深层链接路由。要发送与被评估应用所需主机或路径匹配的精心构造的深层链接，请改用发送器标签页的隐式深层链接模式。

adb 示例：

adb shell am start -W \
  -a android.intent.action.VIEW \
  -d 'my-authorized-scheme://test?source=adb\&message=hello%20world'

当通过 adb shell 发送多个查询参数时，请使用 \&；否则设备 shell 可能会将 & 视为命令分隔符。

预期结果：

• apk-interceptor 打开到拦截器标签页
• 出现一条 RECEIVED 日志条目
• 点击日志条目展开完整的 URI 和参数列表

发送器

使用此标签页在授权测试期间发送受控的 Intent。

模式：

• 隐式深层链接：发送 Intent(ACTION_VIEW, Uri.parse(uri))
• 显式 Activity：向特定的包和 Activity 类发送 Intent

字段和控制：

• URI：用于隐式深层链接模式
• 包名：用于显式 Activity 模式
• Activity 类：用于显式 Activity 模式
• 附加 content:// URI：将本地载荷 URI 设置为 Intent 数据 （仅在显式 Activity 模式下显示；参见下面的说明）
• FLAG_GRANT_READ_URI_PERMISSION：授予对附加载荷 URI 的读取权限
• 发送 Intent

隐式深层链接工作流程：

1. 选择隐式深层链接。
2. 输入与被评估应用深层链接模式匹配的 URI。
3. 点击发送 Intent。
4. 观察被评估应用的行为和 apk-interceptor 日志。

显式 Activity 工作流程：

1. 确认目标 Activity 是导出的且在您的授权范围内。
2. 选择显式 Activity。
3. 输入被评估应用的包名。
4. 输入导出的 Activity 类名称。
5. 可选地启用附加 content:// URI。
6. 点击发送 Intent。

说明：

• apk-interceptor 不知道被评估应用是否安全地处理了 Intent。你必须观察被评估应用的行为、日志或测试工具。
• 在测试目标 Activity 是否将不可信的 Intent 数据传递给 WebView 时，content:// 附件很有用。
• 附加 content:// URI 仅在显式 Activity 模式下提供。载荷作为 Intent 的 data 传递，这会覆盖你在隐式深层链接模式下输入的 URI，因此该选项在那里被隐藏。
• PayloadProvider 未导出。被评估应用只能通过 Intent 中的 FLAG_GRANT_READ_URI_PERMISSION 授予临时读取权限来读取附加的 content:// 载荷。保持该标志启用，并通过 Intent 传递 URI。以任何其他方式打开的 content:// URI 将无法被其他应用读取。

载荷

使用此标签页创建本地 HTML 载荷，并在 apk-interceptor 自己的自测 WebView 中验证 JavaScript 桥接语法。

它包含的内容：

• HTML 编辑器
• 页面加载后评估的 JavaScript 编辑器
• 桥接对象名称
• 生成的 content:// URI
• 保存载荷
• 运行自测
• 自测 WebView
• 桥接结果和控制台日志

生成的载荷 URI 格式：

content://<applicationId>.payload/current.html

提供程序只提供这个固定文件：

filesDir/payloads/current.html

载荷自测工作流程：

1. 在HTML字段中输入或粘贴 HTML。
2. 输入你想本地测试的桥接对象名称，例如 localBridge。
3. 在你的 HTML 中或 JavaScript 编辑器中添加 JavaScript。
4. 点击保存载荷。
5. 点击运行自测。
6. 在日志中查看 BRIDGE_RESULT、console.log 和 evaluateJavascript result 条目。

示例自测 JavaScript：

console.log("payload loaded");
window.localBridge.logResult(window.localBridge.getInfo());

自测桥接暴露了：

window.<bridgeName>.logResult("message");
window.<bridgeName>.getInfo();

重要限制：

自测 WebView 确认你的本地载荷和桥接调用语法在 apk-interceptor 内部工作。它无法观察另一个应用的 WebView 是否执行了你的载荷或调用了它自己的桥接。对于被评估的应用，请通过该应用的 UI、日志、测试钩子或 Chrome DevTools（如果应用可调试）进行验证。

面向漏洞的工作流程

1. 自定义 URI 方案劫持

风险：

一个 Android 应用注册了一个自定义 URI 方案，而不是经过验证的应用链接。任何其他应用都可以注册相同的方案，因此 Android 可能会显示应用选择器或将链接路由到不同的应用。

使用 apk-interceptor 检查：

• 该方案是否可以被另一个应用注册
• Android 是否将 apk-interceptor 作为处理程序提供
• 敏感值是否出现在深层链接参数中

步骤：

1. 从被评估应用的清单或文档中识别其自定义方案。
2. 使用该方案构建 apk-interceptor。
3. 在同一测试设备上安装 apk-interceptor 和被评估应用。
4. 从授权的测试流程触发一个深层链接。
5. 如果 apk-interceptor 接收到它，检查拦截器日志。

要捕获的证据：

• 操作系统的选择器行为（如果显示）
• 接收到的完整 URI
• 查询参数以及它们是否包含敏感值
• 路由链接所需的用户交互

2. 深层链接参数注入

风险：

被评估应用信任深层链接参数用于导航、URL 加载、功能标志、账户选择或渲染，而没有充分的验证。

使用 apk-interceptor 检查：

• 精心构造的参数是否被接受
• 应用是否导航到非预期的屏幕
• 是否使用不安全的 URL/路径/内容值

步骤：

1. 识别被评估应用的深层链接格式。
2. 打开发送器。
3. 选择隐式深层链接。
4. 输入一个带有受控参数的授权测试 URI。
5. 点击发送 Intent。
6. 观察被评估应用的行为。

示例占位符：

my-authorized-scheme://open?next=https%3A%2F%2Fauthorized-test.example%2Flanding

不要使用真实的第三方域或账户，除非它们明确在范围内。

3. 导出 Activity 访问控制

风险：

导出的 Activity 执行敏感操作或显示敏感数据，而不验证调用者、用户状态或所需的授权。

使用 apk-interceptor 检查：

• 导出的 Activity 是否从另一个应用启动
• 它是否在没有预期检查的情况下执行敏感行为
• Intent 数据是否改变其行为

步骤：

1. 确认 Activity 是导出的且在范围内。
2. 打开发送器。
3. 选择显式 Activity。
4. 输入包名和 Activity 类。
5. 可选地附加本地 content:// 载荷 URI。
6. 点击发送 Intent。
7. 观察被评估应用是否强制执行访问控制。

要捕获的证据：

• Activity 已启动或已被阻止
• 任何身份验证或授权提示
• 敏感操作或数据暴露
• Activity 使用的 Intent 数据

4. 通过 content:// 暴露 WebView JavaScript 桥接

风险：

被评估应用将不可信的 content:// Intent 数据加载到一个也通过 addJavascriptInterface 暴露 JavaScript 桥接的 WebView 中。

使用 apk-interceptor 检查：

• 本地 HTML 载荷是否可以作为 content:// 传递
• 目标 WebView 是否加载该载荷
• 来自该源的 JavaScript 是否可以访问桥接

步骤：

1. 在授权分析期间识别目标 Activity 和桥接对象名称。
2. 打开载荷。
3. 创建调用预期桥接的 HTML/JS。
4. 使用运行自测在本地验证你的语法。
5. 打开发送器。
6. 选择显式 Activity。
7. 输入目标包和 Activity 类。
8. 启用附加 content:// URI 并保持启用 FLAG_GRANT_READ_URI_PERMISSION。
9. 点击发送 Intent。
10. 观察被评估应用以确定其 WebView 是否加载了载荷以及桥接调用是否执行。

重要限制：

除非另一个应用显式返回或显示结果，否则 apk-interceptor 无法接收来自它的结果。该工具设计用于传递本地载荷并验证语法，而不是窃取数据。

命令行检查

验证 APK 不请求网络访问：

aapt dump permissions ./out/apk-interceptor-<scheme>-debug.apk

预期输出：没有 android.permission.INTERNET。

显式触发一个深层链接到 apk-interceptor：

adb shell am start -W \
  -n com.sterrasec.apkinterceptor/.InterceptActivity \
  -a android.intent.action.VIEW \
  -d 'my-authorized-scheme://test?source=adb'

通过 Android 的解析器触发一个深层链接：

adb shell am start -W \
  -a android.intent.action.VIEW \
  -d 'my-authorized-scheme://test?source=adb'

显式命令确认 InterceptActivity 的行为。隐式命令确认清单 intent-filter 和解析器的行为。

测试

单元测试使用 Robolectric 在 JVM 上运行，因此不需要设备或模拟器。它们覆盖 PayloadProvider，包括路径白名单和遍历检查，确保提供程序只提供单个 current.html 载荷。

./gradlew testDebugUnitTest

测试结果写入 app/build/reports/tests/testDebugUnitTest/index.html。相同的任务在每次推送到 main 和拉取请求时在 CI 中运行。

设计护栏

• 无 android.permission.INTERNET
• 无外部数据传输或自动窃取
• 无 Shell 命令执行功能
• 无 root、Magisk、Frida 或插桩依赖
• 无运行时注册任意方案
• 无通用文件服务提供程序
• 仅 /current.html 由 PayloadProvider 提供

许可证

MIT