源文件漏洞

去年秋天，源文一个做电商的源文朋友半夜给我打电话，说网站首页被挂了一串菠菜链接。源文我让他先别动服务器，源文登进去看了一眼——首页文件里多了三行iframe，源文指向境外域名。源文他问我怎么进来的源文，我说你先查查最近谁改过模板。源文

结果查出来一个让人哭笑不得的源文答案：他三个月前从某资源站下载了一套"破解版"商城模板，里面有个header.php，源文文件末尾藏了一段base64编码的源文代码。解码后是源文一个远程文件包含函数，攻击者可以通过构造URL参数，源文让服务器加载任意远程文件。源文这三个月里，源文他的网站一直在给别人当跳板。

这就是源文件漏洞最典型的样子——不是服务器被攻破，不是数据库被拖库，而是你亲手把一个后门放进了自己的代码里。

很多人对安全的理解停留在"防火墙够不够厚""密码够不够复杂"。但源文件层面的漏洞完全是另一个维度的问题。防火墙拦不住一个eval($_POST['cmd'])，因为请求看起来完全合法；WAF也识别不了你的模板文件里混入了一段十六进制编码的shell。这些代码就安安静静躺在你的项目目录里，和正常业务逻辑混在一起，不触发特定条件根本不会暴露。

我见过更隐蔽的。一个WordPress站点，functions.php里被插入了一段看起来像正常钩子函数的代码，函数名模仿主题前缀，缩进风格跟周围代码一致。如果不是用diff工具对比了官方主题包，根本不可能发现。这段代码做的事情很简单：在每次页面加载时，向一个Telegram bot发送当前访问者的IP和User-Agent。

这类漏洞的来源主要有几个渠道。第三方模板和插件是最常见的入口，尤其是那些"破解版""绿色版"的资源。攻击者把后门嵌进你需要的功能里，你用得越久，他收集的信息越多。另一个渠道是供应链——你用的某个npm包、composer依赖，可能在某次更新中被注入了恶意代码。2022年那个node-ipc事件就是活生生的例子，一个维护者往里加了段代码，检测到特定IP就覆盖文件内容。

还有一类容易被忽略：开发过程中留下的调试代码。phpinfo()忘了删，display_errors忘了关，数据库连接信息硬编码在config.js里然后不小心提交到了公开仓库。这些不算严格意义上的"漏洞"，但它们是源文件层面的安全隐患，攻击者拿到这些信息后能做的事情比你想的多得多。

怎么防？我的习惯是，任何从外部获取的代码，上线前必须过一遍。不是扫一遍杀毒软件就完事，而是用grep搜几个关键词：eval、base64_decode、exec、system、file_get_contents配合变量。这些函数在正常业务代码里出现频率不高，一旦出现就值得多看两眼。另一个办法是用git diff对比官方版本，所有非官方改动一目了然。

文件完整性监控也得做。用inotify或者auditd盯着网站根目录，任何文件被修改立刻告警。很多主机面板自带这个功能，但默认是关的。打开它，别嫌烦。

最后说个实在的：别用破解版。省那几百块钱，后面可能要花几千块清理后门，还得赔上用户数据。这笔账怎么算都不划算。