如何保障浏览器扩展与Native Host安全通信？及管道相关技术疑问

一、通信安全最佳实践 #

• 严格校验Native Host身份：依赖Chromium原生主机清单（native manifest）的allowed_origins字段，仅允许指定的扩展ID发起连接，这是Chromium原生提供的基础防护，避免任意扩展调用你的Native Host。
• 双向身份验证：建立连接后，扩展和Native Host互相发送加密的验证令牌——比如基于预共享密钥、设备硬件标识生成的签名信息，确认对方是合法实体，防止中间人冒充。
• 端到端加密敏感数据：即使管道有系统层面的隔离，对所有敏感数据都用强加密算法（如AES-GCM）加密后再传输，避免数据被嗅探或篡改。
• 最小权限运行Native Host：让Native Host以最低必要权限运行，限制其文件系统、网络等访问范围，降低被恶意利用后的危害程度。
• 限制管道访问权限：在创建管道时配置安全描述符（Security Descriptor），仅允许Chromium进程和Native Host进程的SID拥有读写权限，即使其他进程枚举到管道名也无法打开连接。
• 随机化管道名称：如果自定义Native Host启动逻辑（而非依赖Chromium默认的管道生成规则），可以生成随机的管道名称，减少被恶意进程枚举的概率，注意要同步扩展端的管道名获取逻辑。

二、Chromium选择Named Pipes的原因及替换可行性 #

为什么用Named Pipes而非匿名管道？ #

• 独立进程连接需求：Chromium的Native Host是通过CreateProcess启动的独立进程，并非浏览器的子进程。匿名管道依赖进程句柄继承，仅适用于父子进程间通信，无法支持这种独立进程间的连接场景。
• 架构灵活性：Named Pipes支持多客户端连接（Chromium实现为一对一，但架构上预留了扩展空间），能适配扩展和Native Host的多实例交互需求；匿名管道是严格的一对一通信，无法满足这种场景。
• 跨平台抽象对齐：Chromium在不同平台采用不同IPC机制：Linux用Unix域套接字，macOS用XPC，Windows用Named Pipes——Named Pipes是Windows平台最适合独立进程间IPC的机制，能和其他平台的IPC实现保持架构抽象一致。

能否改为使用匿名管道？ #

几乎不可行：Chromium的Native Messaging API底层实现深度依赖Named Pipes（Windows平台），若要替换为匿名管道，需要大幅修改Chromium源码（如native_process_launcher_win.cc中的进程启动和管道创建逻辑）。此外，匿名管道的进程继承特性会强制Native Host成为浏览器的子进程，这会带来权限继承、进程生命周期绑定等一系列问题，同时破坏现有Native Messaging的兼容性，完全不符合实际开发需求。

补充：隐藏管道的可行方案 #

你提到用PipeList能获取管道名称，虽然无法完全让管道从系统中“不可见”，但通过配置严格的管道安全描述符，可以让其他进程即使知道管道名也无法访问。具体来说，在创建管道时设置DACL，仅赋予Chromium进程和你的Native Host进程读写权限，恶意进程会因权限不足无法打开管道。

内容的提问来源于stack exchange，提问作者Moaz Fathy