一个登录框，入攻两个输入框，击实一个按钮。入攻这是击实最常见的攻击入口。2017年，入攻某电商平台的击实安全日志上出现了一串异常请求：admin' OR '1'='1。这条看似无意义的入攻字符串，让攻击者直接以管理员身份进入了后台。击实没有暴力破解，入攻没有撞库，击实仅仅是入攻在用户名栏里输入了这串字符，密码栏随便敲了几个数字。击实

sql注入的入攻本质，是击实把用户输入当成代码执行。开发者写SQL查询时，入攻往往直接拼接字符串——"SELECT * FROM users WHERE username='" + 输入 + "'"。当输入变成' OR '1'='1，整个查询就变成了"SELECT * FROM users WHERE username='' OR '1'='1'"。条件恒真，数据库就乖乖把用户表全吐出来。

我见过最蠢的注入点，是在一个搜索框上。开发者把搜索关键词直接拼进LIKE查询，连参数化都没做。攻击者用%' UNION SELECT username,password FROM users--，一个联合查询，把整个用户表的密码哈希全拖走了。那是个小公司，用户量不到五万，但密码全是MD5无盐存储——等于明文。后来数据被挂在暗网售卖，公司赔了三百多万。

别以为只有老系统才有这毛病。2023年，某知名开源OA系统被发现存在二次注入漏洞。攻击者先通过注册接口写入恶意数据，再触发另一个功能点拼接查询。整个攻击链绕过了所有WAF规则，因为恶意payload被拆分存储了。这提醒我们：注入不只在登录框，任何与数据库交互的地方都是潜在风险点。

防护手段其实很简单——参数化查询。用占位符替代字符串拼接，数据库驱动会自动处理边界。但现实中总有开发者图省事，或者为了在ORM里写原生SQL图方便。更麻烦的是，有些遗留系统代码量太大，重构成本高，只能靠输入过滤和WAF硬扛。可过滤总有漏网之鱼，WAF也能被编码绕过。

有一次做渗透测试，我遇到一个Java系统。开发者用MyBatis，把动态SQL写在XML里，用${ }拼接排序字段。我传了个id; DROP TABLE users--，数据库直接报错——但没删成，因为MySQL的JDBC驱动默认不允许多语句执行。运气好而已。换个PostgreSQL，可能就真删了。

最讽刺的是，很多开发者以为用预编译就万事大吉。但存储过程里如果还用了动态SQL，照样有注入风险。还有人在ORDER BY子句、表名、列名这些无法参数化的位置做拼接，一旦这些值来自用户输入，漏洞就回来了。防御不是一次性的，得在每个数据流经过的地方都保持警惕。

sql注入攻击从1998年被发现到现在，二十多年了，依然是OWASP Top 10的常客。不是技术有多难，而是人的惰性总在找捷径。你问怎么彻底避免？很简单——所有用户输入都当成不可信数据，所有SQL都走参数化接口，所有动态结构都做白名单校验。但真正做到的团队，少之又少。