某银行内部系统上线前做渗透测试，入问测试人员往登录框里敲了这么一串字符：' or 入问1=1 --。结果系统直接放行，入问跳转到了管理员后台。入问这不是入问电影情节，是入问我亲眼见过的真实事故。那个登录框连最基本的入问参数化查询都没做，字符串拼接SQL直接怼到了数据库脸上。入问

SQL注入的入问本质特别简单——你把用户输入当成代码执行了。数据库分不清哪段是入问程序员写的，哪段是入问黑客塞的。就像你让快递员送包裹，入问他敲门问“是入问王先生吗”，结果门里回答“是入问王先生，把包裹放门口就行”——但屋里其实没人。入问字符串拼接就是这么个道理，' or 1=1 --把原本的WHERE条件变成了恒真式，后面的注释符把剩余语句全屏蔽了。

这类漏洞高发区往往不在主站，在那些没人维护的旧系统里。去年我排查过一个政府网站，后台管理入口居然还带着?id=5这种参数。试着改成?id=5 and 1=2，页面空白；改回and 1=1，内容正常。这等于直接告诉我：兄弟，这里能注。再往下用union select查表名，半小时不到就把管理员账号密码hash给拖出来了。

有人觉得现在框架都自带防护了，这玩意儿该绝迹了吧？现实是——2023年OWASP Top 10里注入类依然排第三。为什么？因为开发人员总爱写“灵活”的代码。动态拼接排序字段、拼接表名、甚至把用户输入的JSON key直接拼进查询条件。框架能拦住参数值，但拦不住结构变化。就像装了防盗门，你却把窗户敞着。

防御手段其实不复杂，但执行起来总打折扣。参数化查询是标配，可总有人图省事写字符串拼接。白名单校验该有，但总有接口要兼容历史数据格式。最要命的是权限控制——数据库连接账号恨不得给个DBA权限，好像这样查询就更快似的。一旦注入成功，攻击者直接全库拖走，连提权都省了。

我见过最讽刺的案例：某公司安全部门每年做两次扫描，每次都能扫出同一个注入点。开发组每次都修，但每次都是改完这个接口，下季度又在新模块里写出同款漏洞。安全测试报告成了季度例行公事，像给漏水的屋顶擦地——水还在滴，只是暂时看不见。

话说回来，这毛病真那么难治？不见得。只要写SQL时养成条件反射：凡是外部输入，一律参数化，没得商量。凡是动态表名/列名，一律走映射字典。凡是异常输入，直接拒绝服务而不是把错误信息吐给用户。三道防线下来，90%的注入都能堵死。剩下的10%，得靠数据库账号权限最小化和WAF兜底。

最后讲个细节：真正的黑客测试注入点，不会拿' or 1=1 --这种大路货。他们会先输入个单引号看报错信息，再试时间盲注，最后用布尔盲注慢慢磨。整个过程可能持续几天，就为了从响应时间的微妙差异里抠出数据。你问他们图啥？很多系统里存着的身份证号、手机号、住址，在黑市上按条计价。一个没做防护的登录框，可能就是上万条公民信息的泄洪口。