一个登录框，入漏输入 ' or 洞产'1'='1，点提交，原因直接进了后台。入漏这不是洞产电影桥段，是原因很多年前真实发生过的事。SQL注入说到底就一句话：用户输入的入漏数据被当成了SQL代码来执行。问题的洞产根子不在数据库，在写代码的原因人怎么处理输入。

先看一个典型的入漏查询语句。假设有个登录功能，洞产后端拼接SQL大概是原因这个样子：

SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'

正常用户输入 admin 和 123456，拼出来没问题。入漏但攻击者在用户名框里填 admin' --，洞产密码随便写。原因拼接后变成：

SELECT * FROM users WHERE username = 'admin' --' AND password = 'xxx'

-- 在SQL里是注释符，后面的密码验证直接被注释掉了。数据库只检查用户名是不是admin，密码条件形同虚设。一条语句，绕过整个认证。

为什么这种拼接方式如此普遍

早期Web开发没什么框架，PHP、ASP、JSP都是手写SQL。拼接字符串是最直觉的写法，教科书上也这么教。问题在于，开发者脑子里想的是“用户会老老实实填用户名”，但攻击者不会。

更深一层的原因：SQL语言本身把数据和指令混在一起。在SQL的世界里，admin 是一个值，OR 是一个操作符，它们通过引号来区分。当用户输入能突破引号的边界，就完成了从“数据”到“代码”的越权。这不是数据库的bug，是接口设计上把两种东西放在同一个通道里传输。

我见过一个案例。某系统有个搜索功能，URL参数是 ?id=1，后端直接拼进 WHERE id = $id。攻击者传 ?id=1 UNION SELECT username, password FROM admin_users，直接把管理员表的数据查出来显示在页面上。开发者的反应是：“参数不是数字吗？”他没做类型检查，也没做参数化查询，默认用户会传数字——这就是典型的信任边界错位。

参数化查询为什么能解决问题

参数化查询的核心逻辑是：先把SQL语句的结构固定下来，再把用户输入作为纯数据填进去。数据库收到的是“这是一条查询语句，这里有个占位符”，而不是“这是一条查询语句加上用户输入的代码”。

比如上面那个登录，改成参数化写法：

SELECT * FROM users WHERE username = ? AND password = ?

用户输入 admin' -- 作为username参数传进去，数据库只会把它当成一个字符串值去匹配，引号和注释符都失去语法意义。攻击面从根上被堵死。

但参数化查询不是银弹。有些场景没法用，比如动态表名、动态排序字段（ORDER BY ? 在多数数据库里不生效）。这时候需要白名单校验，而不是退回去拼接。我见过有人用参数化处理值，但表名还是拼接的，结果在表名参数里注入 users; DROP TABLE logs，照样出事。

还有一个容易被忽略的入口

HTTP头。User-Agent、Referer、X-Forwarded-For，这些字段经常被日志系统记录，而日志系统可能把请求头直接拼进INSERT语句。攻击者伪造一个User-Agent为 ' , (SELECT password FROM admin)--，如果日志写入用的是拼接SQL，数据就被注入到日志表里，后续查询日志时可能触发二次注入。

这类漏洞的修复成本其实很低——参数化查询改几行代码的事。但发现成本高，因为不是每个拼接点都能被代码扫描工具覆盖到。有些老系统里，SQL散落在几百个文件里，审计一遍要命。

说到底，SQL注入不是技术难题，是习惯问题。写代码的人愿不愿意在每一个数据库交互点上都用参数化，愿不愿意对无法参数化的部分做严格白名单。攻击者不需要找一百个漏洞，找到一个没做好的拼接点就够了。

(责任编辑：百科)