sql渗透

2019年夏天，一个做安全测试的朋友给我发了条消息：“你猜我在客户后台里翻到了什么？”他扔过来一张截图，是一个登录框，URL后面挂着?id=1'。就这一个单引号，数据库报错信息直接弹在了页面上——MySQL版本、当前库名、甚至表前缀都写得清清楚楚。他说：“这玩意儿就像门没锁，还贴了张纸条告诉你钥匙在哪儿。”

SQL注入的本质就这么简单：你写代码的时候，把用户输入直接拼进了SQL语句里。用户输入本该是数据，结果被数据库当成了命令。比如登录验证，代码写成SELECT * FROM users WHERE username='$user' AND password='$pass'，攻击者在用户名框里填admin' --，密码随便写。拼接后SQL变成SELECT * FROM users WHERE username='admin' --' AND password='xxx'，--后面的内容全被注释掉，密码验证直接绕过。

我见过最离谱的案例是一家小电商网站。商品详情页的URL是product.php?id=100，后端直接SELECT * FROM products WHERE id=$_GET['id']。攻击者把id改成1 UNION SELECT username,password,3,4 FROM admin，页面直接把管理员账号密码渲染出来了。前后不到三分钟。这种漏洞不需要什么高深技术，一个浏览器地址栏就够。

有人觉得参数化查询是银弹。确实，PreparedStatement能把数据和指令彻底分开，MySQL的预处理协议让注入几乎不可能。但现实里坑很多。我审计过一个Java项目，用的MyBatis，开发图省事写了${ id}而不是#{ id}。${ }是字符串拼接，#{ }才是参数化。一个符号的区别，整个框架的防护就废了。还有更隐蔽的——ORDER BY后面不能参数化，有些开发者就直接拼字符串，结果ORDER BY id变成ORDER BY id,(SELECT ...)，照样注入。

宽字节注入也值得提一嘴。GBK编码下，%df%27经过转义函数addslashes会变成%df%5c%27，但%df%5c在GBK里是一个合法汉字，把反斜杠“吃掉”了，单引号逃逸出来。这个技巧十年前流行，现在有些老系统还在用GBK，照样中招。

说点实际的。如果你在写代码，永远不要相信任何来自客户端的数据。URL参数、POST body、Cookie、HTTP头，统统当敌人处理。参数化查询是底线，不是加分项。如果实在没法参数化，比如表名、列名动态拼接，白名单校验——只允许字母数字下划线，长度限制死。别用黑名单，SELECT被过滤了还有SELSELECTECT，绕过方式比你想的多。

从攻击者视角看，手工注入其实比工具更有意思。sqlmap确实快，但有时候一个AND 1=1和AND 1=2的页面差异，比工具跑半天都直观。报错注入、布尔盲注、时间盲注，三种基本手法覆盖九成场景。时间盲注最磨人，IF(ASCII(SUBSTRING(database(),1,1))>100,SLEEP(3),0)，一个字符猜半天。但没别的办法的时候，它就是能出数据。

最后说个观察。SQL注入被OWASP列为十大安全风险这么多年，按理说应该绝迹了。但每年护网行动，它还是能打进内网。原因不复杂——老系统没人敢动，新系统赶工期，开发觉得“先上线再说”。安全这东西，永远是出了问题才被重视。我那个朋友后来把漏洞报告交上去，客户第一反应是“能不能别写进报告里”。你看，问题从来不只是技术。