2019年夏天，网站我在一个安全论坛上看到有人贴出一张截图：某省级三甲医院的注入预约挂号系统，输入单引号后页面直接报错，网站数据库版本号赫然写在错误信息里。注入这不是网站孤例。SQL注入这件事，注入二十多年了，网站依然活得很好。注入

先说一个反直觉的网站事实：任何接受用户输入并拼接进SQL语句的网站，都可能存在SQL注入。注入注意，网站是注入“任何”。不是网站只有小网站、老网站才会中招。注入2023年，网站某头部云服务商的控制台被白帽挖出注入点，赏金拿了六位数。大厂有安全团队尚且如此，中小型站点的情况可想而知。

哪些类型的网站最容易踩坑

根据我这些年跟踪漏洞披露平台的经验，有几类网站是重灾区。

政府类和事业单位网站。这类站点往往外包给本地集成商开发，验收完就没人管了。我见过一个区级教育局的招生系统，登录框用 ' or '1'='1 直接绕过密码。后台数据库是SQL Server 2008，连补丁都没打全。为什么？因为维护合同到期了，没人续费，系统就那么挂着。

电商和团购平台的老旧模块。主站往往防护到位，但那些三四年没更新的促销页面、积分兑换接口、订单查询入口，经常是注入的温床。2021年某团购平台的数据泄露，根源就是一个被遗忘的旧版API，参数没做过滤，攻击者用sqlmap跑了不到十分钟就拿到了用户表。

在线教育平台。这个可能很多人没想到。课程搜索、成绩查询、讨论区发帖——每个功能背后都是数据库操作。我测试过一个在线题库网站，搜索框输入 %' and 1=1-- 和 %' and 1=2--，返回结果数量不同，典型的布尔盲注。他们连预编译都没用。

物联网设备的管理后台。摄像头、路由器、智能门锁的Web管理界面。固件里的Web服务器通常是轻量级的，开发者把精力放在功能上，安全？不存在的。Mirai僵尸网络当年就是靠这类漏洞横扫设备。

为什么这些网站逃不掉

技术原因很朴素：字符串拼接。开发者写代码时，用户输入直接塞进SQL语句里。比如 SELECT * FROM users WHERE id = ' + userId + '。用户输入 1' OR '1'='1，语句就变成了永真条件。

预编译语句能解决这个问题，但很多老系统用的是PHP的mysql_query、ASP的RecordSet，或者Java的Statement而不是PreparedStatement。改造成本高，没人愿意动。

另一个原因是WAF（Web应用防火墙）给了虚假安全感。有些运维觉得部署了WAF就万事大吉。但WAF规则可以被绕过——大小写混合、内联注释、编码变形，方法多的是。我见过一个站点，WAF拦截了 union select，但没拦 union/**/select。就多两个字符的事。

怎么判断一个网站有没有

最直接的方法：找到带参数的URL，比如 product.php?id=10，把10换成 10'。如果页面报错、空白、或者返回内容异常，就有嫌疑。再试 10 and 1=1 和 10 and 1=2，对比返回结果。如果不同，基本可以确认。

但我要说清楚：未经授权测试别人的网站是违法的。上面这些方法，只能用在你自己拥有或明确授权的目标上。想练手，去DVWA、sqli-labs这些靶场。

SQL注入没有消失，它只是藏在了那些没人维护的角落。每一次数据泄露新闻背后，可能就是一个五年前写的、没人再看一眼的查询语句。技术债这东西，迟早要还。