sql注入漏洞，入漏说白了就是洞类攻击者把sql代码塞进输入框，骗过数据库执行。入漏这玩意儿从1998年曝光到现在，洞类依然是入漏owasp top 10的常客。我见过太多开发人员觉得“参数化查询就万事大吉”，洞类结果被一个order by子句打回原形。入漏

先看最常见的洞类数字型注入。你写个`where id=1`，入漏攻击者传`1 and 洞类1=2`，页面不显示内容，入漏再传`1 and 洞类1=1`，内容回来了——这就确认了注入点。入漏这种漏洞多出现在老旧的洞类cms系统里，开发时图省事直接拼字符串。入漏有个做电商的朋友跟我说，他们后台的订单查询接口就这么被拖了库，黑客把整个users表dump下来，在暗网论条卖。

字符型注入稍微绕点弯。你输入`admin' or '1'='1`，如果登录框直接拼了`where username='admin' or '1'='1'`，那就直接以admin身份登进去了。这种漏洞在搜索框、留言板特别常见，因为开发往往只对输入做了转义，没考虑单引号闭合问题。有个细节很多人忽略——如果网站用的是gbk编码，宽字节注入能绕过addslashes函数，把`%bf%27`变成`縗'`，这招对付老phpmysql站点一打一个准。

更阴险的是报错注入。攻击者故意构造`updatexml(1,concat(0x7e,(select database()),0x7e),1)`，让数据库把查询结果直接吐在报错信息里。我见过一个政府网站，搜索框报错信息完整暴露了数据库版本、表名、甚至root密码哈希。运维说他们开了debug模式忘了关，这种低级失误在真实渗透测试里出现频率高得吓人。

盲注才是真折磨人。页面不显示任何数据库报错，只能通过页面是否正常来判断条件真假。时间盲注最经典——`if(ascii(substr((select password from users limit 1),1,1))=97,sleep(3),0)`，响应慢3秒说明猜对了。我做过一次测试，用二分法逐字符猜一个32位md5密码，跑了整整11个小时。但你别小看这笨功夫，sqlmap几秒钟就能自动化跑完，这就是为什么工具普及后，连脚本小子都能打穿防护薄弱的站点。

堆叠注入算进阶玩法。分号隔开多条语句，比如`1;delete from orders`，如果数据库支持多语句执行，直接删库跑路。现实中多数连接池会禁止堆叠查询，但sql server和postgresql在某些配置下能执行。有个做支付系统的朋友说他们遇到过黑客用堆叠注入往日志表里插入假交易记录，差点导致对账出错。

还有个经常被忽略的点——http头注入。referer、user-agent、x-forwarded-for这些字段如果被直接拼进sql，照样出问题。很多waf只检查请求体，忽略了请求头。一次渗透测试中，我往cookie里塞了`' union select username from users-- `，竟然真把管理员的会话id给带出来了。

别以为用了orm就安全。如果开发手写原生查询，或者在order by、group by、limit这些无法参数化的位置拼接输入，依然会中招。更别提存储过程里的动态sql，那简直是给攻击者开的后门。

说句难听的，sql注入漏洞治理了二十多年，本质上还是人祸。框架提供了预编译，偏有人图方便用字符串拼接。waf部署了，却没人更新规则库。安全测试做了，但只测了登录接口，没管导出功能。数据库权限给了sa或root，就为了省事少建几个账号。技术从来不是瓶颈，懒才是。