sql注入总结

sql注入这玩意儿，入总活了二十多年还没死透。入总OWASP Top 10里它年年上榜，入总可现实中还是入总有大把站点栽在单引号上。

原理说白了就一句话：把用户输入当代码执行了。入总你让用户填个用户名，入总他给你填 ' or 入总1=1 --，如果后端直接拼SQL语句，入总那查询条件就废了。入总攻击者能拿到整个表，入总运气好还能getshell。入总

我印象最深的入总一次是看某电商后台的登录接口。开发把密码字段直接拼进SQL，入总连参数化查询都没用。入总攻击者只需要在密码框里输入 ' OR '1'='1，入总就能以管理员身份登录。更蠢的是，那个接口还暴露在公网上，连个频率限制都没有。这代码是怎么过review的？我至今没想通。

注入点分三种：字符型、数字型、搜索型。字符型要闭合引号，数字型直接拼数字就行，搜索型最阴间——它会把你的关键字塞进LIKE子句，很多新手以为加了百分号就安全了，结果被%' OR 1=1 --打穿。

检测手段也分三六九等。老手喜欢用sleep(5)看响应时间，或者用extractvalue报错回显。新手还在那一个个试and 1=1，累不累啊？直接上sqlmap多省事。但工具归工具，你得能看懂它吐出来的payload，不然被WAF拦了都不知道怎么绕。

绕WAF是门手艺活。注释符、大小写混合、内联注释/*!50000*/、编码绕过，这些招数在真实环境里比教科书上的例子管用多了。我见过最骚的操作是把payload拆成多段，用CONCAT拼起来，硬生生把检测规则给骗过去了。

但说真的，防御没那么难。参数化查询能挡掉99%的注入，剩下1%是存储过程和动态SQL的锅。ORM框架也不是万能药，你要是写裸SQL查询照样中招。最怕的是那种“我这系统老，改不动”的借口——老系统才更需要加白名单校验和输入过滤。

有个案例特典型。某政府网站用的老代码，所有参数都拼SQL。后来被拖库了，几百万条公民信息挂在暗网上卖。事后调查报告写得跟论文似的，结论就俩字：活该。代码上线前不做安全测试，出事了才想起来补救，这行业里太多这种人了。

再补一句，现在很多云厂商的WAF能自动识别常见注入特征，但别太依赖它们。攻击者手里有各种奇技淫巧，比如用JSON格式传参绕过解析，或者利用multipart/form-data边界混淆。你永远不知道下一个绕过姿势长啥样。

所以我的建议很粗暴：所有数据库操作必须走预编译，动态拼接一律禁止。实在要拼，那就把输入字符集给锁死，数字只留0-9，字符串只留白名单字符。丑是丑了点，但比裸奔强。

最后说个冷知识：很多开发以为把错误信息隐藏了就安全。其实不然，报错注入只是最基础的手段，盲注照样能把数据一点一点抠出来——时间盲注每次只能拿一个bit，但人家有耐心啊。你堵住了显错，人家就用二分法慢慢猜，一天不行就一周，反正脚本不睡觉。

sql注入这事，本质上是信任和验证的失衡。你把用户输入当自己人，它就给你上眼药。别总想着怎么花式防御，先把基础夯实了——参数化、最小权限、定期扫描，这三板斧下来，能挡住绝大多数攻击。剩下的，就交给运气吧。