上周三凌晨两点，网站我盯着屏幕上一条返回包，存漏状态码200，网站内容却是存漏一串不该出现的数据库报错。那个电商站点，网站商品详情页的存漏URL里有个参数叫`item_id`，我把它从`1001`改成`1001'`，网站页面直接吐出了MySQL的存漏语法错误。注入点，网站就这么赤裸裸地躺在那里。存漏

这不是网站什么高深的技术活儿。一个单引号就能撬开数据库的存漏大门，说明后端代码压根没做参数化查询。网站我顺着报错信息里的存漏表名`orders`和`users`，用联合查询把管理员密码哈希拖了出来。网站整个过程没超过二十分钟，工具就是浏览器和Burp Suite。网站用的是某款国产CMS，版本号在页脚版权信息里写得明明白白，网上搜一下，公开的EXP一抓一大把。

漏洞从来不是孤立的。这个注入点背后，是整套开发流程的松懈。我翻了一下该站点的静态资源，JS文件没压缩，注释里留着测试环境的API地址，`/api/v1/debug`这个端点甚至不需要认证就能访问，返回当前数据库连接配置。运维那边呢？服务器直接暴露了phpMyAdmin，默认路径，默认端口，登录页面连验证码都没有。你很难说清到底是哪个环节先失守的——每个环节都在给攻击者递刀子。

有人觉得SQL注入是老掉牙的话题，WAF一挡就完事。我试了一下，该站点确实装了某云WAF，但只拦`union select`这种经典 payload。我把注入语句改成`union/**/select`，中间加个内联注释，WAF直接放行。绕过规则库的代价低得可怜。更讽刺的是，报错信息里泄露的数据库账号是`root`，权限全开。运维图省事，开发图省事，最后省出来的是一条直通核心数据的通道。

我联系了网站管理员。邮件发过去三天没回音，电话打过去，对方第一句是“我们网站有什么好黑的”。这句话我听过太多次。很多中小型站点的负责人根本意识不到，漏洞利用不挑目标大小，自动化扫描器每天在互联网上爬，匹配到指纹就丢payload。你的站点可能不值钱，但你的服务器可以被用来发垃圾邮件、挖矿、当跳板。黑产不挑食。

后来那个管理员加了我微信，发了个红包，我没收。他问怎么修，我说先把`item_id`强制转成整数，再关掉错误回显，phpMyAdmin换个路径加个IP白名单，WAF规则更新一下。他问能不能帮忙改，我说你找个开发吧，这活儿不该我干。其实我心里清楚，他大概率不会改。很多漏洞的修复不是技术问题，是优先级问题。只要没被拖库、没被勒索，就永远排不上日程。

写这篇文章的时候，我又去那个站点看了一眼。`item_id=1001'`，页面返回500，但不再报数据库错误了。不知道是修了还是WAF升级了。我换了个参数`sort`，加了个单引号，页面正常返回。再试`orderby`，报错又出来了。你看，修了一个点，漏了另一个。安全这事儿，从来不是一劳永逸的补丁，是持续跟自己的懒惰和侥幸较劲。