去年帮一个朋友看他的入漏小电商站，后台登录框随便输了个 ' or 洞复1=1 --，直接进了管理页。入漏他当场愣住，洞复问我是入漏不是黑客。其实这就是洞复最基础的 SQL 注入，连工具都没用。入漏

SQL 注入的洞复本质很简单：网站把你输入的内容拼进 SQL 语句里执行，而你输入的入漏东西改变了原语句的逻辑。拿登录来说，洞复后端代码可能是入漏这样写的：

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

正常输入 admin / 123456，拼出来就是洞复 WHERE username = 'admin' AND password = '123456'，没问题。入漏但如果密码框里填 ' OR '1'='1，洞复语句变成：

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1';

'1'='1' 永远为真，入漏整个 WHERE 条件被绕过，数据库返回第一条用户记录，通常是管理员。登录成功。

搭个环境实际跑一遍

我用 PHP + MySQL 在本地复现。建一张 users 表，插两条数据：admin / secret123，testuser / 123456。登录页面的 PHP 处理逻辑不做任何过滤，直接拼接：

$sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'"; $result = mysqli_query($conn, $sql);

浏览器访问登录页，用户名填 admin，密码填 ' OR '1'='1。提交后页面直接跳转到后台首页，连密码都不需要知道。

换个玩法。用户名填 ' UNION SELECT 1,version(),database() -- ，密码随便。因为原查询返回两个字段（假设是 username 和 password），UNION 后面也必须跟两个字段。页面如果会把查询结果回显出来，你就能直接看到 MySQL 版本和当前数据库名。我本地跑出来是 8.0.35 和 testdb。

再进一步，用 ' UNION SELECT 1,group_concat(table_name) FROM information_schema.tables WHERE table_schema=database() -- 把所有表名拖出来。information_schema 是 MySQL 自带的元数据库，里面存着所有表结构信息。拿到表名之后，同样的方式读列名、读数据。整个过程不需要任何专业工具，浏览器地址栏就能完成。

为什么这种漏洞至今还在

按理说 SQL 注入被讲了二十年，应该绝迹了。实际情况是，中小型项目里依然常见。原因不复杂：很多快速上线的项目用字符串拼接写 SQL，开发觉得“先跑起来再说”，安全审查排不上优先级。我见过一个后台管理系统，十几处查询全是拼接，参数过滤只做了一个 addslashes()，遇到宽字节注入照样穿。

另一种情况是 ORM 用了一半。比如 ThinkPHP 的 where 方法传数组是安全的，但有人偏偏用 where("id = " . $_GET['id'])，等于白用框架。

防御就一条路

参数化查询。PDO 的 prepare + bindParam，或者 mysqli 的预处理语句，把 SQL 结构和数据彻底分开。用户输入永远不会被当成 SQL 代码执行。这是唯一靠谱的方案，没有之一。

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?"); $stmt->execute([$username, $password]);

输入过滤、WAF、转义函数都只是辅助手段，能挡一部分攻击，但挡不住所有变种。根子上还是得靠参数化查询。

如果你手上有站点，现在就打开登录框，输一个单引号试试。报 SQL 语法错误，说明存在注入。别等被人拖了库才想起来修。