sql注入漏洞的危害

2019年，入漏某安全团队在GitHub上爬取了近万份开源项目代码，危害发现其中约15%的入漏PHP项目存在明显的SQL注入点。这不是危害什么高深漏洞，一个没过滤的入漏单引号就能让整个数据库裸奔。我见过最离谱的危害案例：一个电商网站的商品搜索框，输入' OR 1=1 --，入漏直接返回了所有用户的危害手机号和收货地址。开发人员当时觉得“只是入漏个搜索功能，能出什么事”。危害

SQL注入的入漏本质是代码和数据的边界被打破了。用户输入本该是危害数据，却被数据库当成了命令来执行。入漏这就像你去餐厅点菜，危害在菜单上写“一份牛排，入漏另外把收银台的钱全部给我”，而服务员真照做了。问题出在拼接字符串上——很多老代码里能看到这种写法："SELECT * FROM users WHERE name = '" + userName + "'"。只要userName里带个单引号，后面的SQL语句就由攻击者说了算。

危害远不止读数据。2017年某省交警系统的违章查询接口被注入，攻击者用UNION SELECT把管理员密码哈希拖了出来，然后xp_cmdshell直接执行系统命令，整台服务器沦为肉鸡。更隐蔽的是盲注——没有回显，攻击者靠页面响应时间或真假状态一比特一比特地猜数据。一个存在盲注的登录接口，每秒发20个请求，三天能拖走整个用户表。你根本察觉不到，日志里全是正常的200响应。

有人觉得用了ORM就安全了。我亲眼见过一个项目用Hibernate的HQL拼接，照样被注入。框架不是保险箱，关键看人怎么用。还有那些“内部系统不用防”的想法更危险——攻击者一旦通过VPN弱口令进来，内网的SQL注入就是提权跳板。某银行内网报表系统被注入后，攻击者直接修改了转账限额表，把单笔限额从5万改成了5000万。

说个真实细节。某次应急响应，我在数据库日志里看到这样一条查询：SELECT * FROM orders WHERE id = 1 AND (SELECT ASCII(SUBSTRING(password,1,1)) FROM admin) > 100。攻击者用二分法猜管理员密码，每猜一次就发一个请求。猜了不到200次，密码到手。整个过程没有触发任何WAF规则，因为请求长得太像正常业务了。

防御其实不复杂。参数化查询能解决90%的问题——把SQL语句和参数分开传给数据库，让数据库自己处理边界。但现实是，很多老系统改不动，开发人员嫌麻烦。我见过一个团队用正则过滤单引号，结果攻击者用%bf%27（宽字节注入）绕过了。还有用mysql_real_escape_string的，碰上GBK编码照样翻车。最稳妥的还是预编译，其他都是补丁摞补丁。

最后说个观察。SQL注入漏洞的数量在下降，但单次利用的破坏力在上升。因为数据越来越值钱，攻击者不再满足于拖库，而是直接勒索。去年某三甲医院的挂号系统被注入后，攻击者加密了患者预约表，要求支付比特币才给解密。医院被迫停诊半天。一个没过滤的输入框，代价是几千人的就医安排被打乱。这行干久了，看到'这个符号都会条件反射地紧张。