WebView与组件交互：JavaScript桥接漏洞、File协议访问风险与Native组件交互的安全隐患

WebView，说白了就是Android里嵌入的一个浏览器内核。它让App既能用Native的流畅，又能享受H5的灵活。但问题来了——这个“混合体”恰恰是攻击者最喜欢下手的地方。

我做过不少App的代码审计，WebView相关的漏洞几乎每两个项目就能碰到一个。有些是开发图省事，有些是压根没意识到风险。今天咱们就把这块掰开揉碎了讲清楚。

JavaScript桥接漏洞：Native与Web的“危险通道”

先说说最常见的——JS桥接。Android提供了@JavascriptInterface注解，让JS可以直接调用Java方法。听起来很方便对吧？但方便往往意味着风险。

我记得有一次，一个金融类App找我做安全评估。他们的JS桥接里有个方法叫getUserSensitiveData()，直接返回用户的身份证号和银行卡信息。更离谱的是，这个方法没有任何权限校验——任何加载到WebView里的JS都能调用。

为什么会这样？说白了，很多开发者觉得“我的WebView只加载自家服务器上的页面，不会有问题”。但你想想看，如果页面被XSS攻击了呢？如果用户通过第三方链接打开了你的WebView呢？

常见的JS桥接漏洞类型

• 无权限校验的敏感方法暴露——任何JS都能调用，包括恶意脚本
• 反射调用漏洞——Android 4.2以下版本，JS可以通过反射调用任意Java方法
• 参数注入——JS传入的参数未做校验，直接拼接到Native命令中执行

安全实践：如何正确使用JS桥接

我个人习惯遵循“最小暴露原则”——只暴露绝对必要的方法，而且每个方法都要做来源校验。

// 安全的JS桥接示例
public class SafeBridge {
    private Context mContext;
    private String mAllowedOrigin = "https://trusted.example.com";
    
    @JavascriptInterface
    public void sendData(String data) {
        // 1. 校验调用来源
        if (!isFromTrustedOrigin()) {
            Log.w("SafeBridge", "Blocked call from untrusted origin");
            return;
        }
        
        // 2. 参数校验
        if (data == null || data.length() > 1024) {
            return;
        }
        
        // 3. 使用白名单过滤
        if (!isValidData(data)) {
            return;
        }
        
        // 4. 执行实际逻辑
        processData(data);
    }
    
    private boolean isFromTrustedOrigin() {
        // 获取当前加载页面的URL，校验是否在白名单中
        return true; // 实际实现需要完整校验逻辑
    }
}

File协议访问风险：本地文件的“隐形大门”

File协议，就是file:///开头的URL。它允许WebView直接读取设备本地文件。听起来很实用？但风险也很大。

你想想看，如果攻击者能控制WebView加载的页面，或者通过某种方式注入恶意JS，那他们就能用file:///data/data/com.example.app/shared_prefs/这样的路径，直接读取你的SharedPreferences文件。里面可能存着token、密码、甚至支付密钥。

File协议的主要风险场景

风险类型	具体描述	危害等级
本地文件读取	通过file://协议读取App私有目录下的文件	高
目录遍历	使用../等路径穿越技巧访问上级目录	高
跨域数据泄露	file协议页面可以访问其他域下的本地资源	中
XSS升级为文件读取	XSS攻击结合file协议读取敏感文件	极高

如果确实需要加载本地文件，比如展示本地HTML帮助文档，我建议用ContentProvider或FileProvider来封装文件访问，而不是直接暴露file协议。

// 禁用File协议访问
WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setAllowFileAccess(false); // 关闭file协议
settings.setAllowFileAccessFromFileURLs(false); // 关闭file域下的跨域访问
settings.setAllowUniversalAccessFromFileURLs(false); // 关闭通用跨域访问

与Native组件交互的安全隐患

WebView不是孤立的。它经常需要和Activity、Fragment、甚至Service交互。这些交互路径，每一个都可能成为攻击面。

我见过一个案例：某个社交App的WebView里有个“分享到朋友圈”按钮。点击后，JS通过桥接调用了一个Native方法，这个方法直接启动了Intent.ACTION_VIEW，而且Intent的data是从JS传过来的。攻击者只要构造一个恶意链接，就能让用户手机自动拨打电话、发送短信，甚至安装恶意APK。

常见的交互安全隐患

• Intent Scheme劫持——JS通过桥接启动任意Intent
• Activity劫持——恶意页面覆盖在合法Activity之上
• 数据泄露——WebView页面内容被其他App通过辅助功能读取
• 中间人攻击——HTTPS证书校验不严，导致交互数据被窃听

知识体系总览

下面这张图，我把WebView与组件交互的核心风险点和防护措施梳理了一下。你可以把它当作一个快速参考。

总结一下

WebView与Native组件的交互，说白了就是“信任边界”的问题。你让一个不可信的Web页面，通过桥接、File协议、Intent等方式接触到Native层，就必须做好层层防护。

我个人习惯在做WebView相关开发时，先问自己三个问题：

1. 这个WebView真的需要JS桥接吗？能不能用postMessage替代？
2. 真的需要加载file://协议吗？能不能把文件放到assets目录或者用ContentProvider？
3. JS传过来的数据，我做了校验吗？有没有可能被用来启动恶意Intent？

这三个问题想清楚了，WebView的安全风险至少能降低80%。剩下的20%，就需要靠代码审计和渗透测试来发现了。

---

公众号:蓝海资料掘金营，微信deep3321