网站整改报告

网站被挂马那天，网站我正在外面吃饭。整改手机弹了条监控告警，报告点开一看，网站首页被注入了一段iframe，整改指向一个博彩站点。报告说实话，网站第一反应不是整改慌，是报告烦——这套系统跑了三年，一直没出过大问题，网站偏偏赶在流量高峰前出事。整改

先做了紧急处理：把首页模板回滚到上一个版本，报告同时封掉那个iframe指向的网站域名。但这只是整改止血，漏洞还在。报告我花了大概四十分钟定位入口，最后发现是后台一个文件上传接口没做后缀白名单，攻击者传了个伪装成图片的PHP文件上去。这个接口是两年前加的，当时为了赶一个活动页面，临时写的代码，后来忘了补校验逻辑。

问题不止一个

顺着这条线往下查，发现类似的历史遗留问题还有好几处。比如用户评论区的富文本过滤，只在前端做了转义，后端直接存了原始HTML。再比如某个API接口的鉴权token写死在JS文件里，任何人打开开发者工具都能看到。这些问题单独拎出来都不致命，但凑在一起，整站基本等于敞着门。

我列了个清单，按风险等级排了序。最紧急的是文件上传和SQL注入相关的两个点，当天晚上就改完了。文件上传加了MIME类型校验和扩展名白名单，同时把上传目录的执行权限关掉——这个操作其实早就该做，一直拖着没弄。SQL注入那个点是因为一个老接口还在用字符串拼接查询，改成了参数化查询，前后不到十行代码。

第二天处理中危项。富文本过滤挪到了后端，引入了一个成熟的白名单过滤库，不再自己写正则。token那个问题稍微麻烦一点，因为涉及前端调用方式的改动，最后换成了后端签发临时凭证，前端每次请求动态获取。改完之后顺手把接口的请求频率限制也加上了，之前完全没有。

有些坑是自己挖的

整改过程中翻出了一些有意思的东西。比如日志里其实早就有异常上传的记录，但没人看。监控只配了服务器层面的CPU和内存告警，应用层的异常行为完全没覆盖。还有代码仓库里有个分支，最后一次提交是去年三月，里面有个没合并的PR，标题写着“修复上传漏洞”，但一直没人review，就那么搁着了。

这事让我意识到，技术债这东西不是慢慢积累的，是某几个瞬间集中产生的。赶进度的时候写的代码，如果当时没补上安全措施，后面大概率也不会再补。除非出了事。

整改做完之后，我加了一层简单的WAF规则，主要拦常见的注入和上传攻击特征。又写了个定时脚本，每天扫一遍上传目录，发现可执行文件就自动隔离并告警。这些措施谈不上多高级，但能挡住大部分自动化扫描工具。

最后说个细节。修复完成那天，我重新扫了一遍站，确认没有残留后门。结果在某个不起眼的目录下发现了一个webshell，文件名伪装成正常的缓存文件，修改时间和正常文件混在一起。清掉之后，我把整个站的文件做了完整性校验，生成了基线哈希，以后每天比对一次。这个事没人要求我做，但我觉得有必要。网站安全这种事，靠一次整改解决不了所有问题，得让它变成日常动作。

很赞哦!（41）