webpack漏洞：不是工具的问题，是信任链的裂缝

2023年三月，一个名为webpack-dev-server的漏洞让无数前端团队连夜加班。攻击者只需要构造一个特殊请求，就能在开发服务器上执行任意代码。这个漏洞的CVSS评分是9.8，几乎满分。讽刺的是，webpack本身是构建工具，它打包的是代码，却没想到自己成了攻击入口。

我见过太多团队把webpack配置当成"写一次就完事"的静态文件。他们不知道，webpack生态的漏洞往往不是webpack核心代码的问题，而是插件和loader的信任链断裂。某个维护者离职后留下的npm包，可能就成了供应链攻击的跳板。去年那个影响广泛的event-source-polyfill事件，就是攻击者拿到了维护者的npm账号，往包里塞了挖矿脚本。而webpack的配置里，只要有一个loader引用了这个包，整个构建过程就沦陷了。

更隐蔽的是配置注入。很多团队喜欢用webpack.config.js里动态拼接路径，比如entry: './src/' + process.env.APP_NAME + '/index.js'。如果环境变量能被外部控制，攻击者就能通过路径遍历读到服务器上的敏感文件。这不是理论攻击，我在实际渗透测试中就遇到过——某个企业的CI系统暴露了环境变量接口，攻击者把APP_NAME改成../../../../etc，webpack构建时直接把passwd文件打包进了bundle。

还有个常被忽略的点：webpack的eval模式。开发环境下很多人为了调试方便开启devtool: 'eval'，这等于把源码直接暴露在浏览器端。如果站点有XSS漏洞，攻击者可以轻松读取整个应用的源代码，包括API密钥、内部逻辑。生产环境用source-map也不安全，我见过有公司把.map文件部署到CDN上，等于把后端接口文档免费送人。

别指望升级版本就能解决一切。webpack 5确实修复了不少已知问题，但核心问题在于使用方式。我见过一个团队，把所有第三方库都打包进一个bundle，体积超过5MB。他们为了优化加载速度，用了SplitChunksPlugin，但配置不当，导致某些公共模块被重复打包，反而增加了攻击面——每个重复的模块都可能包含不同的依赖版本，某个老版本的lodash如果有已知原型污染漏洞，就能通过这个入口被利用。

说实话，webpack漏洞的根源在于它太灵活了。灵活意味着复杂，复杂意味着容易出错。你可以在配置里做任何事，但也意味着攻击者能在你的构建链上做任何事。我建议每个团队都做一次依赖审计，不是那种跑一下npm audit就完事的，而是真正检查每个loader、每个plugin的维护状态和最近更新记录。那些两年没更新的包，就该被替换掉。

最后说个实际案例。有个朋友的公司，前端代码被注入了一段挖矿脚本，查了三天才发现是某个图片压缩loader的依赖被劫持了。那个loader只是用来压缩jpg的，没人想到它会成为突破口。修复方式很简单——把那个loader换成纯本地实现的工具，不经过npm安装。但这件事让他们整个技术部反思了一周：我们到底信任了多少看不见的代码？

webpack本身没错，错的是我们把它当成了黑盒。每个构建工具都是供应链上的一环，而供应链攻击最可怕的地方在于，你根本不知道哪一环会断。