[原创]黑盒视角下的 WebView 漏洞面探索-WEB安全-看雪安全社区

[原创]黑盒视角下的 WebView 漏洞面探索

发表于: 2026-2-10 14:13 4050

[原创]黑盒视角下的 WebView 漏洞面探索

KEEEY

2026-2-10 14:13

4050

# 黑盒视角下的 WebView 漏洞面探索

## 前言

本文主要记录了在移动端探索 WebView 组件漏洞的过程，采用黑盒视角，摒弃复杂繁琐的内部逻辑分析，专注于快速且直接的漏洞挖掘方法。由于笔者才疏学浅，因此本文难免会出现一些文笔不通或专业解释不到位的情况，还望多包涵及斧正。

## WebView 组件

### 介绍

顾名思义，WebView 组件是用于在应用程序中嵌入和展示 Web 内容的系统组件。通过调用 WebView，开发者能够实现在自己的应用中直接渲染网页，这从某种程度上极大地简化了跨平台应用的开发流程。利用 WebView，开发者只需进行少量适配工作，即可将现有的 Web 应用无缝移植到移动应用环境中，显著提升了开发效率和灵活性。

### 场景

WebView 组件实际上无处不在。例如，在手机上打开一个商城 APP 时，展示的商品信息可能本质上就是通过 WebView 加载和渲染的网页。在这些实际应用场景中，用户通常不会察觉到 WebView 的存在，并且所有显示的信息可能都是由 APP 预先配置好的。

## 漏洞入口

要想让用户手机上的 APP 调用 WebView 组件对自定义页面进行渲染，方法主要分为两种：**第一类是国内常见的二维码扫码，通过扫描一个指向网页链接的二维码，从而直接调用 WebView 加载特定网页；第二类是 APP 间的跳转调用，即 URL Scheme（在安卓上也称为 Deep Link），通过这种方式可以从一个 APP 直接跳转到另一个 APP 中的特定页面，而这个页面同样可能是通过 WebView 来渲染的。**

### 二维码扫描

APP 上的二维码扫码功能通常作用于用户界面的左右上角，如果找不到的话则可以在 APP 的设置页面中找到“扫一扫”、“扫码”等字眼就可以打开相关功能。

![图片描述](upload/attach/202602/943869_SY76253VUZCWJTR.webp)

### URL Scheme 跳转

关于 URL Scheme，对于我来说就是老熟人了，在 2018 年的时候就在博客里浅浅的分享了一下，有兴趣可以看下：<mark class="encrypted">011K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9o6m8K6N6q4)9J5k6h3y4F1i4K6u0r3j5i4u0U0K9r3W2$3k6i4y4Q4x3V1j5J5x3o6p5^5i4K6u0V1x3e0u0Q4x3X3b7H3z5q4)9J5c8U0q4Q4c8e0y4Q4z5o6m8Q4z5o6t1`.</mark>

这里简单说明下，URL Scheme 实际上是应用程序在操作系统层面注册的一种自定义协议格式，它允许 APP 定义特定的协议名，并在 APP 内定义路由和接收参数来完成某些功能，与我们所理解的 HTTP 协议形式的 URL 地址没有什么本质区别。当其他应用或浏览器尝试通过这种自定义协议发起请求时，系统能够识别并定位到相应的应用程序，然后传递所访问的功能路由和参数信息给该应用进行处理。

在 iOS 和 Android 上，对于 URL Scheme 的支持是不一样的，例如在 iOS 上的 Safari 浏览器的地址栏中直接输入 URL Scheme 则可以完成跳转调用。而 Android 默认浏览器下，用同样的方式则会提示找不到网页，因此想要调用 URL Scheme 就需要借助 JavaScript（location 跳转）或 HTML（a 标签 href 点击指向）的方式，在 iOS 上也可以用这种方式。

```html
<a href="xapp://page?url=https://gh0st.cn">Click</a>
```

![图片描述](upload/attach/202602/943869_NHGC6A7FWKRC8E7.webp)

## 实战案例

基于以上所述的两种攻击入口，我发现了许多 APP 上的漏洞，可以通过 WebView 组件直接获取用户凭证。

### WebView 访问

访问获取凭证是 WebView 组件漏洞面的最基本漏洞，通过扫描二维码或 URL Scheme 跳转调用 WebView 组件打开指定的 URL 地址，接着由于 APP 为设限或存在绕过的情况下，WebView 内访问指定的 URL 地址时会携带凭证信息。

**为什么 WebView 内访问可以携带凭证？** 因为当前 APP 的设计架构采用 Native UI 与 WebView 相结合的方式，以兼顾性能体验与业务灵活性，支持更丰富的应用场景，因此在 APP 上进行登录后，APP 在 WebView 的应用场景下也会携带登录凭证。

#### 二维码扫描

关于二维码扫描的方式比较简单找到入口，如上文所说在 APP 那找到对应功能点即可。以下图所示，图中所展示的案例就是最经典的二维码扫描入口进入 WebView 组件，访问时携带了凭证到达指定 URL 地址。（可以将 URL 地址设为 BurpSuite Collaborator 的地址或类似有 HTTP Log 记录的地址）

如图所示案例实际上有个细节，如二维码内容处打码的部分即为白名单域名，可以通过抓包或知道 APP 归属的域名方式获取该部分。很多 APP 使用 WebView 组件进行访问时，会判断当前访问的页面 URL 地址中的域名部分，有些 APP 在此处判断时比较宽松，例如判断域名是否包含某域名。因此可以通过一些格式对此进行绕过，如：`<mark class="encrypted">899K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8W2!0q4y4#2)9&6z5g2!0n7c8q4!0q4y4g2)9&6x3q4)9^5c8q4!0q4y4g2)9^5c8q4)9&6y4g2!0q4y4g2)9&6c8W2)9&6c8W2!0q4y4g2)9&6x3q4)9^5c8q4)9J5k6f1S2f1g2q4m8x3L8$3N6Q4x3X3g2U0L8$3#2Q4y4U0m8Q4c8e0y4Q4z5o6m8Q4z5o6q4Q4y4U0m8Z5N6s2c8H3i4K6y4m8i4K6u0r3i4K6u0r3i4@1f1%4i4K6V1&6i4@1u0p5i4@1f1#2i4K6V1H3i4K6S2p5i4@1f1#2i4K6S2p5i4K6V1#2i4@1f1#2i4K6W2r3i4K6W2r3i4@1f1#2i4K6V1H3i4K6S2p5i4K6b7H3d9q4c8f1f1p5I4G2k6#2)9J5k6h3y4G2L8g2)9$3x3q4!0q4x3#2)9^5x3q4)9^5x3R3`.`.</mark>

![图片描述](upload/attach/202602/943869_A2Z4SVD5TYKV2HW.webp)

#### URL Scheme 跳转

URL Scheme 按常规逻辑需要通过工具查看 APP 所声明的信息，APK 格式就是文件内的 `AndroidManifest.xml` 文件，IPA 格式就是文件内的 `Info.plist` 文件。但是本文不做偏逆向/白盒侧的分享，从黑盒角度出发获取 URL Scheme。

**为什么可以从黑盒出发获取 URL Scheme？** 还是回到 Native UI 与 WebView，因为 WebView 会去访问一些业务/功能页面，因此开发也会在 WebView 网站中去写入 APP 的 URL Scheme 信息，从而调起 APP 内的一些 Native 功能，因此只要可以进行抓包即可通过正则匹配的方式获取到完整的 URL Scheme 信息。

如下图所示案例逻辑为：

1. 通过笔者所开发的 HaE 工具配合 BurpSuite 进行抓包，规则就会获取到抓包过程中所出现的 URL Scheme 信息：`xxx://clause/WebView?url=`。
2. 得到该信息之后，将其中的 url 参数设为 HTTPLog 地址：`xxx://clause/WebView?url=<mark class="encrypted">5f0K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8V1S2f1g2q4m8x3L8$3N6Q4x3X3g2U0L8$3#2Q4y4U0m8Q4c8e0y4Q4z5o6m8Q4z5o6t1`.</mark>
3. 在 iOS 环境下即可通过浏览器复制构建好的地址直接打开然后跳转到 APP 内的 WebView 访问界面。在 Android 环境下，则可以按上文中提到的 HTML 代码方式进行。
4. 最后在 HTTPLog 服务中即可查看是否获取到了凭证信息，如果没有也可以尝试绕过，与二维码扫描处的绕过逻辑是一样的。

![图片描述](upload/attach/202602/943869_SVGYHP2WNQWDMY6.webp)

### JSBridge 获取

#### 逻辑与发现

JSBridge 是一种在 App 中实现 JavaScript 与 Native 代码通信的技术方式，可以将 Web 页面中的 JavaScript 调用映射到原生功能中。很多 APP 在使用 JSBridge 映射 JavaScript 与 Native 方法时，未对调用来源的域（Origin）进行校验或白名单限制，导致任意网页或第三方脚本均可通过 JavaScript 直接调用注册的 Native 接口。

这些被注册的接口，可以是全局变量、方法、对象等类型。在 JavaScript 中全局实际上就是窗口对象 Window。也就意味着这些接口都会被注册到 Window 下面。因此，只要进入到 WebView 组件内就可以通过遍历 Window 全局对象的方式来找到被 APP 所注册的接口。

如下代码所示就是一个简易的 Window 全局对象遍历代码。它的缺点很明显，如图所示会将浏览器/组件自带的一些方法遍历出来，因此就需要加入输出过滤功能，从而帮助我们更方便的进行 APP 注册接口的寻找。

```html
<body>
</body>
<script>
    Object.keys(window).forEach(key => { document.body.innerHTML += `<pre>${key}:${window[key]}</pre>`; });
</script>
```

#### 凭证获取

依旧使用 HaE 的规则通过抓包的方式来获取到 WebView 的 URL Scheme 信息：`xxx://promotion/web`，有些 URL Scheme 信息需要分析业务 JavaScript 文件中的逻辑，如图所示在基础的 URL 信息上还有一个参数 `url`：`xxx://promotion/web?url=`。

![图片描述](upload/attach/202602/943869_M8PK65N4GN849Z2.webp)

如下图所示案例逻辑为：

1. 编写 A 标签跳转页面，用于指定 WebView 组件跳转页面：`<a href="elink@3f8P5s2S2^5i4K6y4m8i4K6u0r3i4K6u0r3M7s2u0G2L8h3!0@1K9h3!0F1i4K6u0r3N6$3g2T1i4K6y4r3N6i4u0D9i4K6y4p5K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8W2!0q4y4g2)9^5c8W2!0m8c8W2!0q4y4q4!0n7c8W2!0m8x3g2!0q4y4g2)9&6c8W2)9&6c8W2!0q4y4g2)9&6x3q4)9^5c8q4)9J5k6h3q4@1N6r3q4U0K9#2)9J5k6h3y4G2L8g2)9J5c8W2N6W2j5W2k6A6k6i4N6Q4x3V1j5H3i4K6u0W2K9s2c8E0L8l9`.`.">Click Me</a>`。
2. 打开跳转页面点击 A 标签，调用起目标 APP 的 WebView 组件访问自动化遍历脚本页面，分析发现 `czbInfo.getAppInfo` 方法可以获取凭证。
3. 构建 JavaScript 外带代码用于验证凭证可以经过网络进行远程获取。

![图片描述](upload/attach/202602/943869_ZEDH2GR49EXFHBT.webp)

## 总结与思考

本文从黑盒测试的视角，梳理了针对移动端 WebView 组件的漏洞挖掘路径。但是 WebView 组件不仅仅是移动端的特有产物，随着类 CEF （Chromium嵌入式框架）/ 类 Electron 框架的出现，PC客户端也同样面临着 WebView 组件攻击风险。

抛出两个思考：除了获取凭证外是否存在其他更高维度的利用面？除了APP自身校验缺陷外是否存在系统层的校验不严格问题？

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

#漏洞

收藏・4

点赞・3

打赏