测试sql注入

把单引号塞进搜索框，测试页面炸了。测试数据库报错信息像内脏一样翻出来，测试裸露在浏览器上。测试这就是测试SQL注入最原始的样子——不是电影里黑客敲几个命令就能拖库的酷炫场面，而是测试程序员少写一行过滤代码，就留下一个能让任何人翻墙的测试后门。

我见过最蠢的测试注入点，是测试一个登录框。用户名输入admin' OR '1'='1，测试密码随便打，测试直接进后台。测试那系统是测试给某家连锁药店用的，后台能改药品价格。测试要是测试有人手贱把胰岛素改成一分钱，仓库得亏到裤衩都不剩。可写这代码的哥们儿大概只想着“能跑就行”，压根没想过有人会跟输入框较劲。

测试注入有个笨办法，也挺有效——把所有输入点都当作精神病患者来对待。正常的搜索框，你打“感冒药”，它返回结果。你打' AND SLEEP(5)--，页面卡了五秒才出来。行了，时间盲注确认，这地方能灌。用延迟当信号，跟谍战片里对暗号似的，一个参数一个参数试过去，直到数据库疼得喊出声。

更阴险的是报错注入。有些系统配置了详细错误信息，你输入' AND extractvalue(1,concat(0x7e,(select database())))--，页面底部直接吐出版本号和库名。这种测试就像撬锁——先试探锁芯松不松，再用特定工具拧一下，门开了，你甚至不用硬闯，人家把钥匙放门口垫子底下了。

但别高兴太早。现在的网站没几个裸奔的，参数化查询和ORM框架把大部分洞都堵了。你拿SQLMap跑一整天，可能全部返回“无注入点”。这时候得换思路——找那些被遗忘的接口，比如老管理后台的导出功能，或者第三方插件留下的调试页面。这些地方往往还留着五年前的代码风格，字符串拼接SQL跟写日记一样随意。

有个真实案例让我印象很深。某政务网站，所有公开页面都封得严严实实，唯独一个附件下载接口，文件名参数直接拼进SQL。测试时输入' UNION SELECT username,password FROM users--，返回的居然是一张表格，管理员账号密码整整齐齐排在里面。那密码是明文存储的，还是“admin123”。我当时就想，这安全审计的钱真好赚。

写代码的人总爱说“用户输入不可信”，但真到自己写的时候，又觉得“哪来那么多黑客”。这种侥幸心理才是最大的洞。SQL注入的本质不是技术漏洞，是懒惰和傲慢。你测试得越多，越发现大部分漏洞不是多高深，就是没人愿意多写三行校验代码。

测试完记得收尾，把注入痕迹清干净。别学某些人，测出洞来还留个后门，下次来直接拖库。这行当有底线，你能发现漏洞，说明你懂系统，但拿漏洞去换钱，那就变味了。我一般测完就写报告，告诉对方“你这里能裸奔”，修不修是他们的事，反正我不负责给他们擦屁股。

最后说句实在的，SQL注入这玩意儿，从1998年被人公开讨论到现在，二十多年了还在各种新系统里冒头。不是因为技术多难防，是因为每代新程序员都在重复犯同样的错。你测试的水平再高，也追不上他们挖坑的速度。所以啊，看到输入框就多想想，别光顾着填自己的名字。