渗透测试sql注入

一个登录框，渗透输入`admin' or 测试'1'='1`，回车。渗透后台数据库直接吐出了所有用户记录。测试这不是渗透电影情节，是测试我上周在客户那儿亲眼看到的。他们的渗透财务系统，用了十年，测试没人管过输入框。渗透

SQL注入的测试本质就一句话：把用户输入当成代码执行了。你在查询语句里拼了个字符串，渗透那个字符串里藏着SQL命令，测试数据库傻乎乎地照单全收。渗透就这么简单，测试但每年OWASP Top 10里它就没掉出过前三。渗透

拿个真实案例说事儿。某电商平台，商品详情页的id参数是`product.php?id=5`。攻击者把id改成`5 AND 1=2 UNION SELECT username,password FROM users`——好家伙，整个后台管理员的密码哈希全出来了。更讽刺的是，他们用的还是老掉牙的MySQL 5.7，连参数化查询都没做。

我能说什么？技术债迟早要还的。开发图省事拼字符串，DBA没做输入校验，安全测试就扫了个端口。层层失守，最后数据库裸奔在公网上。

做渗透测试的时候，我习惯先摸接口。不是所有参数都叫id，有些藏在JSON里，有些在HTTP头里。最阴的是那种二次注入——第一次存进去的时候没事，等下次查询把存储的数据再拼进SQL时才触发。这种坑，静态扫描工具基本抓瞎，只能靠手工慢慢试。

有个细节挺有意思。很多新手以为SQL注入只能靠单引号判断，其实不然。数字型参数根本不需要引号，直接`AND 1=1`和`AND 1=2`对比响应差异就行。布尔盲注、时间盲注、报错注入——每种手法都是跟数据库特性的博弈。比如MySQL的`extractvalue`函数报错，Oracle的`UTL_HTTP`请求外带，都是老油条们的最爱。

防御呢？别跟我提什么WAF，绕过姿势多到能写本书。最靠谱的还是参数化查询——让数据库把输入当数据，不当代码。再配合最小权限原则，连接数据库的账号只给SELECT权限，就算被注了也翻不出大浪。对了，还有一点容易被忽略：错误信息别原样抛给前端。我见过不少系统，直接把SQL报错堆栈打到页面上，等于给攻击者递刀子。

说个我自己的判断：未来五年，SQL注入不会消失。原因很简单——存量系统太多，改造要花钱花时间，老板们觉得“能跑就行”。但风险这东西，不出事则已，一出事就是拖库、勒索、监管处罚三连击。

最后留个观察：你去翻翻那些被公开的漏洞报告，八成以上都是SQL注入。它不炫酷，不高级，但就是扎扎实实地躺在那儿，等着某个粗心的开发者写下第一个拼接字符串的瞬间。