SQL 注入怎么防：参数化查询、ORM 边界与五个仍然高危的写法

约 7 分钟读完 · 更新于 2026-10-21 · 文中每条都能在下面的配套工具里动手验证

一个单引号就进去了：注入到底发生在哪一步

登录框输入 a' OR '1'='1 能绕过鉴权，不是因为数据库「读不懂」你的意思，而是因为你把不可信输入当成了 SQL 文本的一部分去拼。参数值一旦能改变语句的结构，注入就成立了：多出来的引号提前闭合了字符串字面量，后面的 OR '1'='1 就变成了 WHERE 条件的一部分。分清「值」和「语法」是全部防御的起点——让值只能是值，语法只能由你自己写。

// 输入： a' OR '1'='1  --
query("SELECT * FROM users WHERE email = '" + email + "' AND active = 1");

// 数据库实际收到：
SELECT * FROM users WHERE email = 'a' OR '1'='1' AND active = 1
//                    ↑ 字符串在这里就结束了      ↑ 这段变成了 WHERE 条件

stmt = conn.prepare(
  "SELECT id, email FROM users WHERE email = ? AND active = ?"
);
stmt.execute([email, 1]);

// 数据库实际收到：语句文本与 email 的值分开传输
// email 无论等于什么，都只是那一个槽位里的一个字符串

症状 → 真正的成因 → 修法：一张对照表

排查注入问题不要从头读代码，从异常形态反查更快。下面这些症状每一条都对应一类固定的拼接错误。

参数化为什么有效：语句和值走两条路

所谓「预编译」不是把 SQL 提前算好，而是让数据库分两步处理：第一遍解析固定的语句结构，第二遍才把参数值填进去。值到达解析器之前就已经是数据，永远没有机会被当作语法读取。这也是为什么只做「转义」不管用：转义的正确性取决于你枚举得全不全，而参数化把「枚举」这件事从根上去掉了。

五个仍然高危的写法：参数化管不到的地方

参数化只覆盖「值」。下面这些位置语法上就要求放标识符或片段，驱动 API 只能拼字符串，这是必须人工把关的地方。

1. 表名与列名：MySQL 没有「参数化的列名」。ORDER BY / GROUP BY / 字段列表一律走白名单字典映射，输入只当 key 用。
2. IN 列表：不要自己拼 a,b,c，用驱动提供的数组绑定（Python 的 IN (%s) 加 seq，Node 的 IN (?) 加数组），或先生成一段固定长度的占位符。
3. LIKE 的通配符：绑定的是值，但 % 和 _ 仍是 LIKE 自己的语法，必须先转义再绑定，并显式写 ESCAPE。
4. 数字字段：把 id 拼进 WHERE id = ... 这种写法，即使 id 看起来是数字也要绑定。类型来自客户端时它就是个字符串。
5. 动态排序方向：ASC / DESC 不能参数化，只能 if/else 二选一；传其他值时回退到默认顺序，不要回显原值。

const sql = "SELECT * FROM orders ORDER BY " + req.query.sort + " " + req.query.dir;
// ?sort=id,(SELECT password FROM users LIMIT 1)  → 报错信息直接带出密码

const SORTABLE = { createdAt: "created_at", total: "amount_cents" };
const column = SORTABLE[req.query.sort] ?? "created_at";
const dir = req.query.dir === "asc" ? "ASC" : "DESC";

const [rows] = await db.query(
  `SELECT id, total FROM orders WHERE user_id = ? AND id IN (?) ORDER BY ${column} ${dir}`,
  [userId, ids]                     // 数组驱动自动展开为 ?,?,?
);

// LIKE：先转义 % 与 _，值再绑定
const kw = "%" + term.replace(/[\\%_]/g, (m) => "\\" + m) + "%";
await db.query("SELECT id FROM post WHERE title LIKE ? ESCAPE '\\'", [kw]);

ORM 也不是免罪符：哪些接口会拼字符串

• 原生片段类：whereRaw、rawQuery、queryRaw、extra、RawSQL、UnsafeRaw——这些就是拼接入口，白名单规则照旧适用。
• 排序类：orderBy 接受字符串字段名时，必须先过白名单；ORM 不会替你校验列名是否存在。
• 批量写入类：批量 insert 的 values 列表要么走参数批量绑定，要么自己拼——先确认它真的参数化了。
• 迁移脚本类：迁移里的 SQL 常被开发者信任，但生产表名可能来自配置或分表规则，一样要参数化或白名单。
• 存储过程类：动态 SQL 拼在过程体内部，逃过了应用的检查，评审时容易整段漏掉。

上线前的五条自查：按这个顺序过一遍

这五条不需要工具就能做，但第四、第五条建议真的动手：脏数据比推理更能暴露问题。

1. 全仓搜拼接痕迹：把 " + 、${、format(、%s 拼进 SQL 的位置全找出来，逐个判断这个位置是值还是标识符。
2. 确认驱动用的是真正的绑定：某些 ORM 的 where 传字符串时仍会内联，尤其是嵌套条件与原生片段。
3. 给每个外部入口配一条恶意输入的集成测试：带单引号、带 --、带 /*、带 UNION SELECT，长度超长，四条都过才算覆盖。
4. 把脏数据灌进测试库：用 <a class="faq-link" href="/tools/mock-data/">随机测试数据生成</a>造一批姓名、备注、备注里塞引号和逗号的行，再跑一遍全部查询。
5. 看异常信息是否泄露结构：故意触发一次语法错误，确认对外响应只有一句「请求无效」，SQL 片段和表名不进错误消息、不进日志对外通道。

已经被注入了怎么办：按攻击者已经拿到的东西来处置

发现注入漏洞时，清理输入是第一步，不是最后一步。攻击者可能已经通过同一个洞读过数据、写过后门、种下二阶注入（存储型数据下次被别的查询拼接时再触发）。处置顺序：堵住入口（参数化 + 最小权限账号）→ 审日志找异常查询（大范围 SELECT、information_schema 探测、异常时间的批量读）→ 检查写入侧有没有被改过的数据 → 轮换可能泄露的凭据。把漏洞和凭据分开处理，只修代码不换密钥等于没修。

常见问题