reversing-browser-extensions

逆向分析浏览器扩展

浏览器扩展是一种权限较高的小程序，会伴随用户访问的每个页面运行。它的安全性几乎完全取决于一个边界：内容脚本运行在不可信的网页内容旁边，却能与拥有实际权限的后台上下文通信——这些权限包括 Cookie、标签页、网络，有时还包括原生进程。逆向分析扩展，就是检查这个边界，并找出拥有特权的一侧在何处信任了不具备特权的一侧。

适用场景

• 分析可疑、权限过多或来源不明的扩展的行为
• 审计扩展的清单和消息传递机制，查找权限泄漏
• 调查内容脚本如何向页面暴露后台或原生功能
• 查明扩展实际执行的操作与商店页面所声称的内容有何不同

不适用场景

• 将扩展打包的 JavaScript 反混淆作为代码阅读问题处理——使用 reversing-obfuscated-javascript 分析打包文件，然后回到这里检查权限模型。
• 在事件响应中引爆恶意扩展并提取 IOC——使用 analyzing-malware。
• 测试扩展所交互的 Web 应用——使用 testing-web-applications。
• 只是嵌入了浏览器的桌面应用——使用 testing-thick-clients。

获取代码并阅读清单

扩展以 CRX（Chrome）或 XPI（Firefox）格式发布——两者都是 ZIP 归档；解压后即可阅读。你可以从商店的 CRX 端点获取已发布的扩展，也可以直接从浏览器配置文件的 Extensions 目录获取。

清单是路线图。在查看任何代码之前，先阅读清单：

• manifest_version——MV2（后台页面、webRequest 阻止功能）与 MV3（后台服务工作线程、declarativeNetRequest、禁止远程代码）之间的区别。版本会改变特权逻辑所在的位置及其持久化方式。
• permissions 和 host_permissions——<all_urls>、tabs、cookies、webRequest、debugger、nativeMessaging、scripting。根据扩展声称的功能逐项判断；一个“深色主题”扩展同时请求 <all_urls> 和 cookies，就是可疑信号。
• content_scripts——扩展会注入到哪些页面，因此其内容会暴露给哪些页面。
• externally_connectable——哪些 Web 来源可以直接向扩展发送消息；过于宽松的值会扩大攻击面。
• web_accessible_resources——页面可以加载的扩展文件，这可能会泄露扩展的存在，或暴露可注入的资源。
• content_security_policy——放宽的 CSP（unsafe-eval、远程脚本）会形成代码注入面。

信任边界

扩展的设计本就彼此隔离；漏洞出现在不同上下文的交界处：

• 页面 ↔ 内容脚本。 内容脚本运行在隔离世界中—— 它与页面共享 DOM，但不共享 JS 变量。泄漏发生在 DOM 和 window.postMessage： 如果内容脚本处理 postMessage 数据时不检查 event.origin/event.source， 注入范围内的任何页面都能控制它。
• 内容脚本 → 后台/服务工作线程。 内容脚本会将消息转发到后台上下文， 以执行特权操作（chrome.runtime 消息传递）。如果后台处理程序不验证发送方和 消息格式，遭到入侵的页面或恶意页面（通过内容脚本）就能访问 特权 API。这是扩展漏洞的核心：仅凭页面可影响的消息就放行特权操作。
• onMessageExternal / externally_connectable。 列在此处的网页 可直接与后台通信——验证问题相同，只是少了一跳。
• 原生消息传递。 nativeMessaging 将扩展连接到本地原生主机二进制文件。此处 如果消息路径验证薄弱，就可能导致从浏览器到原生代码的代码执行；追踪原生主机如何处理收到的内容。

对于每项特权功能，请回答：有哪些输入会到达该功能？这些输入可能来自多远的地方 （仅后台、内容脚本，还是任意页面）？

需要标记的问题

• 权限范围过宽，与功能不成比例。
• 未验证消息发送方：runtime.onMessage / onMessageExternal 中存在此问题时，会形成从页面到扩展的权限提升路径。
• 内容脚本中处理 postMessage 时未检查来源。
• 远程代码 / eval，或允许其执行的 CSP（这也违反 MV3 政策）。
• 数据外泄——向与声明用途无关的端点发送流量；读取页面内容、表单字段或 Cookie 并将其发送出去。
• 原生消息传递到会处理未经验证输入的主机。
• 更新/供应链风险——扩展会加载远程配置或代码，或者其所有权近期发生变更。

必要时进行反混淆

商店中的扩展经常经过压缩或打包，恶意扩展则会使用混淆。如果代码难以阅读， 请将整个包交给 reversing-obfuscated-javascript——在那里解包并反混淆，然后根据上述信任边界审查 还原出的逻辑。在浏览器的扩展程序 DevTools 中调试正在运行的扩展， 观察运行时的消息传递。

应当驳斥的说法

• “商店审查过，所以没问题。” 商店审查较为粗略，且经常被绕过；所有权变更后， 原本干净的扩展可能在一次更新中变为恶意扩展。要阅读它实际发布的代码。
• “内容脚本经过沙盒隔离，所以页面遭到入侵也影响不到 扩展。” 隔离世界只隔离 JS，不隔离 DOM 或 postMessage。未经检查的消息处理程序就是桥梁。
• “后台只是转发消息。” 如果它将受页面影响的消息转发到特权 API，却不验证发送方， 那么这个转发过程就是漏洞。
• “它只请求所需的权限。” 应根据实际行为进行验证。 <all_urls>、cookies、debugger 和 nativeMessaging 是会让小漏洞演变成大问题的权限。
• “代码经过压缩，所以我无法审查。” 压缩是可逆的；先解包并反混淆，再进行审查。

参考资料

• reversing-obfuscated-javascript — 解包并反混淆扩展的 JS
• analyzing-malware — 对已确认的恶意扩展进行引爆分析并提取 IOC
• testing-web-applications — 扩展会访问的网站和 API
• auditing-supply-chain — 所有权变更和远程代码更新风险