上个月帮一个做跨境电商的网站朋友看站点，刚打开后台就发现事情不对——订单列表里混进了一堆乱码用户名，安全点进去看详情，漏洞收货地址栏赫然写着一串SQL语句。整改不用猜，报告注入漏洞被人盯上了。网站更离谱的安全是，他们技术负责人三天前就收到了监控告警，漏洞但觉得“只是整改扫描器在瞎跑”，没理。报告

这就是网站大多数安全事件的真实起点：不是黑客多高明，是安全运维自己把门敞着。

一、漏洞漏洞是整改怎么被发现的

那次排查用了两个工具交叉验证。AWVS扫了一遍，报告报出12个高危；手工用BurpSuite重放请求，确认了其中3个可以实际利用。最要命的一个在商品搜索接口，参数没做过滤，直接拼进SQL查询。我构造了个' OR 1=1 --，页面返回了整张用户表的前20条记录，包括邮箱和密码哈希。

另一个是文件上传点。前端做了白名单校验，但后端只检查了Content-Type。把PHP文件改成image/jpeg，直接传上去，访问路径就能执行。朋友说这个上传功能是外包团队两年前写的，一直没动过。

二、整改动作

SQL注入那块，把拼接查询全部换成参数化预处理。老代码里还有几处用了mysql_query，这种古董函数早该淘汰了。改完跑了一遍回归测试，搜索响应时间从原来的800ms降到了200ms左右，算是意外收获。

文件上传的修复更直接：后端加了一道getimagesize()检查，同时把上传目录的PHP解析权限关掉。Nginx配置里加了一行location ~* /uploads/.*\.php$ { deny all; }，双保险。

还有个低危但烦人的问题——后台登录没有失败次数限制。用Hydra跑字典，五分钟试了三千多个密码。虽然没跑出来，但服务器CPU直接飙到90%。加了个简单的计数器，同一IP连续失败5次锁15分钟，世界清净了。

三、善后与观察

漏洞修完不是终点。我把这次发现的几个点写成了Checklist，塞进他们的CI流程里。每次代码合并前跑一遍Semgrep规则，至少能拦住80%的低级错误。

另外说个真实感受：很多团队不是不知道安全重要，是觉得“我们小站没人盯”。但现实是，自动化扫描器每天会光顾任何暴露在公网上的IP，跟你站大站小没关系。朋友那个站日活不到两千，照样被爬虫和注入工具轮番问候。

最后留了个后门——不是恶意的那种，是监控。在WAF日志里加了几个告警规则，一旦再出现类似攻击特征，直接发钉钉消息。运维不用天天看日志，但出事得知道。

安全这事，修的是漏洞，补的是习惯。代码写的时候多想想，比事后救火便宜太多。