Chrome插件安全最佳实践：防止XSS、CSRF攻击

Chrome插件安全最佳实践防止XSS、CSRF攻击前言Chrome 插件运行在浏览器的高权限环境里content script 又能直接接触网页 DOM稍不注意就会引入 XSS跨站脚本和 CSRF跨站请求伪造风险。一旦插件被注入恶意内容攻击者就能借插件的权限读取页面、伪造请求后果比普通网页脚本严重得多。插件能拿到的权限比普通网页高所以同样一行有漏洞的代码在插件里造成的危害会被放大这正是我们必须在源头设防的原因。本文用可运行的代码片段讲清楚两条最实用的防线对一切外部内容做转义、对所有跨端消息做校验并以一款多平台视频下载的 Chrome 插件与桌面客户端作为案例背景。读完你应能照着搭出一个基础安全骨架把最常见的两类漏洞挡在门外。下面每段都配有可直接运行的代码你把它们放进自己的扩展目录就能看到效果不必从头造轮子。建议先通读再动手理解每一道防线的位置比单纯复制代码更重要。环境准备浏览器Chrome 88 及以上支持 Manifest V3项目结构manifest.json声明权限与 CSPbackground.jsservice worker处理消息content.js注入页面负责采集popup.js弹窗交互调试打开chrome://extensions开启开发者模式加载已解压的目录。实现步骤1. 在 manifest 中收紧 CSP防止注入脚本执行MV3 默认禁止远程脚本但仍建议显式声明内容安全策略禁止unsafe-inline与eval。这一步是整道防线的基础哪怕后面某处代码写漏了CSP 也会拦下动态注入的脚本。{manifest_version:3,name:安全示例插件,version:1.0.0,permissions:[storage,downloads],host_permissions:[all_urls],background:{service_worker:background.js},content_scripts:[{matches:[all_urls],js:[content.js]}],content_security_policy:{extension_pages:script-src self; object-src self;}}说明script-src self表示只执行插件自身目录下的脚本杜绝外部脚本注入这与多平台视频下载类插件只解析页面已有媒体、不引入第三方脚本的做法一致。2. 转义所有外部内容防止 XSS插件常把页面采集到的标题、作者名渲染进弹窗。任何来自网页的字符串都必须转义绝不能直接innerHTML。下面这个函数覆盖最常见的五个危险字符// utils.js —— 防止 XSS 的转义函数functionescapeHtml(str){if(typeofstr!string)return;returnstr.replace(//g,amp;).replace(//g,lt;).replace(//g,gt;).replace(//g,quot;).replace(//g,#39;);}// 渲染时一律使用转义后的文本functionrenderItem(title){constlidocument.createElement(li);li.textContenttitle;// textContent 不会解析 HTML最安全// 若必须用 innerHTML则li.innerHTML escapeHtml(title);document.getElementById(list).appendChild(li);}要点优先用textContent必须拼 HTML 时先用escapeHtml处理每一个外部变量。别图省事直接拼接一次疏忽就可能让恶意脚本被执行。不要把整段外部数据直接塞进页面先取值、再转义、后渲染。3. 校验跨端消息防止伪造请求CSRF 思路content script 与 background 之间的消息可能被伪造。background 收到消息时应校验来源并校验数据结构。下面这段把来源白名单 结构校验 动作白名单三件事一次做齐// background.js —— service workerconstALLOWED_URL_PREFIX[chrome-extension://];chrome.runtime.onMessage.addListener((message,sender,sendResponse){// 1) 校验发送者合法必须来自本扩展的页面或 content scriptif(!sender.url||!ALLOWED_URL_PREFIX.some(psender.url.startsWith(p))){if(!sender.tab||!sender.tab.url)return;// 未知来源直接忽略}// 2) 校验消息结构拒绝畸形数据if(!message||typeofmessage.type!string)return;// 3) 动作白名单只处理已知类型constHANDLERS{SAVE_MEDIA:(msg){if(typeofmsg.url!string||!/^https?:\/\//.test(msg.url))return;chrome.downloads.download({url:msg.url,saveAs:false});}};if(HANDLERS[message.type])HANDLERS[message.type](message);});要点不信任任何字段URL 必须复核协议头动作走白名单未知类型一律丢弃。宁可多写几行校验也别给伪造消息留口子。4. 给敏感操作加一次性令牌防 CSRF对下载修改设置等敏感动作要求 content script 先申请一次性令牌令牌不匹配则拒绝// 简易令牌background 生成content 端回传校验lettokennull;chrome.runtime.onMessage.addListener((msg,sender,sendResponse){if(msg.typeGET_TOKEN){tokent_Math.random().toString(36).slice(2);sendResponse({token});}if(msg.typeSENSITIVE_ACTION){if(msg.token!token){sendResponse({ok:false});return;}tokennull;// 一次性用完作废sendResponse({ok:true});}});常见问题Q1用了 textContent 还需要 escapeHtml 吗不需要。textContent 不会解析标签是最彻底的防 XSS 方式escapeHtml 是必须用 innerHTML 拼接时的兜底。Q2host_permissions 给all_urls会不会太宽对需要读取任意页面媒体的下载类插件是必要的但要配合上面的消息校验且不要在 content script 里做高危操作。Q3service worker 里 token 会丢吗会。MV3 的 service worker 可能休眠内存中的 token 会清空。生产环境应把令牌存到chrome.storage.session或桌面客户端侧。Q4popup 里的输入要不要也转义要。popup 虽然不直连网页但用户粘贴的内容同样不可信渲染前一律按外部数据处理。Q5光靠 CSP 够不够不够。CSP 是最后一道墙真正的主线仍是“不信任外部输入 校验每一条消息”。两者叠加才稳。Q6桌面客户端和插件之间传数据要注意什么同样要走校验。桌面端只接受来自本扩展插件的消息且对每条指令做白名单与格式检查别把本地接口暴露成任意可调用。Q7上线前怎么自测安全用故意构造的畸形消息去打自己的 background 监听看是否会被丢弃再往页面里塞一段带标签的假标题看弹窗会不会把它当代码执行。两项都扛住基本就稳了。扩展阅读Chrome 官方文档Content Security PolicyMozilla 开发者文档Web 安全中关于 XSS 的说明PortSwiggerWeb 安全学院 CSRF 专题安全清单速记把前面的要点压成一张可勾选的清单转义一切外部输入、优先 textContentmanifest 里收紧 CSP、禁 eval 与远程脚本每条跨端消息都验来源、验结构、走白名单敏感动作加一次性令牌popup 输入同样当不可信处理。五条全勾上日常使用的 XSS 与 CSRF 风险基本就可控了。总结插件的两条安全底线一是对所有外部内容转义、优先用 textContent二是对所有跨端消息做来源与结构校验、敏感动作加令牌。把这两点养成习惯大多数 XSS 与 CSRF 风险都能在源头挡住——对多平台视频下载这类需要接触页面媒体的 Chrome 插件与桌面客户端尤其重要。安全不是上线前加一次开关而是写每一行代码时都不轻信外部输入。把校验当成习惯比任何单点防御都可靠。#Chrome插件开发 #Web安全 #XSS防护 #CSRF防护 #MuxDesk