sql注入漏洞实验

去年帮一个朋友看他的入漏电商后台，登录框输入 ' or 洞实'1'='1，密码随便填，入漏直接进了管理员面板。洞实他脸都白了。入漏这不是洞实电影桥段，是入漏 SQL 注入最经典的入门案例——后端把用户输入直接拼进 SQL 语句，数据库把恶意输入当成了合法指令。洞实

我搭了个本地环境复现这件事。入漏PHP + MySQL，洞实一个极简的入漏登录接口，代码大概长这样：

$sql = "SELECT * FROM users WHERE username = '$user' AND password = '$pass'";

正常输入 admin / 123456，洞实SQL 变成 WHERE username = 'admin' AND password = '123456'，入漏没问题。洞实但输入 admin' --，入漏后面的密码判断直接被注释掉，SQL 只剩 WHERE username = 'admin'。数据库老老实实返回了 admin 那行记录，登录逻辑形同虚设。

更狠的是 UNION 注入。假设查询返回两个字段，攻击者构造 ' UNION SELECT 1, database() --，页面直接把当前数据库名吐出来。我试的时候看到 test_db 出现在原本显示用户名的位置，那种感觉挺微妙的——数据库在替你干活，只不过干的是别人的活。

为什么这种漏洞活了二十多年还没死绝？我翻过一些老项目的代码，发现根子不在技术，在习惯。很多人写代码时脑子里想的是“这个输入框用户会填用户名”，而不是“这个输入框用户可能填任何东西”。思维定势一旦形成，拼接字符串就成了肌肉记忆。ORM 框架普及之后情况好了不少，但手写 SQL 的地方依然遍地是坑，尤其是报表查询、后台筛选这些“临时功能”——临时写的，往往最要命。

防御手段其实就一条铁律：参数化查询。把用户输入当数据传，别当 SQL 代码拼。PHP 里用 PDO 的 prepare + bindParam，Java 用 PreparedStatement，Python 用 cursor.execute(sql, params)。原理都一样——数据库预先编译 SQL 模板，输入只填坑，不参与语法解析。

有人觉得转义函数也能凑合。我做过测试，addslashes() 在 GBK 编码下能被宽字节注入绕过，%df' 这种 payload 照样打穿。转义是黑名单思路，参数化是白名单思路，差距不在一个量级上。

还有个容易被忽略的点：报错信息。开发环境开着 display_errors，SQL 报错直接把表名、字段名、甚至部分语句回显到页面上。攻击者拿这些信息拼图，比盲注快十倍。生产环境关掉详细报错，日志里记就行，别往用户脸上甩。

我自己的习惯是写完任何带 SQL 的代码，先拿 ' 和 -- 各试一遍。花不了两分钟，但能挡住九成以上的低级注入。工具方面，sqlmap 确实强大，一条命令跑出库名表名字段名，但那是攻击视角。防守视角更该关注代码审查——每次 code review 看到字符串拼接 SQL，直接打回去，没得商量。

这个漏洞不新鲜，也不复杂，但它像一面镜子，照出的是开发者对“边界”的态度。输入永远不可信，这句话说了无数遍，真正落到每一行代码里，才算数。