非常好——下面给你一份面面俱到、可立刻落地的 SQL 注入防护手册，包含原理、优先级（最有效先列）、代码示例（常见语言）、检测与测试方法、运维/审计策略，以及常见坑和误区。你可以把它作为开发规范/安全审核清单直接使用。

1️⃣ 核心原则（按优先级）

  1. 使用参数化查询 / 预编译语句（Prepared Statements / Bind Variables） —— 必做、最有效。
  2. 白名单校验（输入 allowlist） —— 对枚举、排序列、分页等结构化参数使用白名单。
  3. 最小权限数据库账号 —— 应用账号只授予必要权限（SELECT/INSERT/…），禁止 DROP、ALTER 等。
  4. 输出编码（contextual output encoding） —— 防止注入到 HTML/JS/SQL/CMD 等其它上下文时被利用。
  5. 错误信息控制与日志审计 —— 不把数据库错误原文返回给用户，记录足够日志用于追踪。
  6. WAF/入侵检测 + 安全测试（动态/静态） —— 局外防护与持续测试。

2️⃣ 最重要的防护：参数化查询（示例）

Java (JDBC)

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setString(1, username);
    ps.setString(2, password);
    ResultSet rs = ps.executeQuery();
    ...
}

Python (psycopg2 / PostgreSQL)

cur.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))

PHP (PDO)

$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute([':email' => $email]);

C# (ADO.NET)

using (var cmd = new SqlCommand("SELECT * FROM Users WHERE Email=@email", conn)) {
    cmd.Parameters.AddWithValue("@email", email);
    using (var rdr = cmd.ExecuteReader()) { ... }
}

要点：永远不要通过字符串拼接把用户输入直接放进 SQL。

3️⃣ 白名单与结构化参数（ORDER BY / column / limit）

  • 对于列名、排序方向、分页大小等结构性参数，不要参数化为 SQL 值；而应使用白名单映射或枚举：
allowed_cols = {"name":"name", "created":"created_at"}
col = allowed_cols.get(requested_col, "created_at")
sql = f"SELECT * FROM items ORDER BY {col} {direction}"
  • direction 只允许 'ASC'/'DESC' 两个值。

4️⃣ 当必须动态构造 SQL 的安全技巧

  • 如果必需动态 IN 列表，使用绑定占位符动态生成同等数量占位符：
ids = [1,2,3]
placeholders = ','.join(['%s'] * len(ids))
cur.execute(f"SELECT * FROM t WHERE id IN ({placeholders})", ids)
  • 避免直接 "... WHERE name LIKE '%" + user + "%'"，若必须用 LIKE，仍使用绑定并对通配符进行转义或在服务器端处理转义。

5️⃣ 存储过程和 ORM 的注意点

  • 存储过程不是银弹：若拼接 SQL 或在存储过程中把参数拼接成 SQL 字符串，会同样受到注入。仍需使用参数化与严格校验。
  • ORM（如 Hibernate, Entity Framework）：大部分 ORM 的查询 API 会自动使用参数化。但当使用原生 SQL（native query）或字符串拼接时，必须遵守参数化/白名单规则。

6️⃣ 转义与字符过滤 — 作为最后防线

  • 不要仅依赖转义或黑名单（容易绕过，多种编码/注释技巧可绕过）。
  • 若必须使用转义，使用数据库驱动提供的 API（例如 mysqli_real_escape_string），但把它当作补充，而非替代参数化查询。

7️⃣ 数据库层面硬化

  • 应用使用专用账号，按功能分账号（查询/写入/DDL分离）。
  • 禁用多语句执行（例如某些驱动有 allowMultiQueries 设置，生产环境建议关掉）。
  • 限制网络访问（数据库仅对应用服务器开放），使用防火墙/私网。
  • 审计与触发器（谨慎使用）可记录异常 SQL 活动。

8️⃣ Web/WAF 与运维防护

  • 部署 WAF（Web Application Firewall）（ModSecurity、云WAF等）做第二道防线。
  • 配置数据库备份、监控慢查询、异常查询频率检测、告警。
  • 对高风险操作（DDL）开启审批/二次认证。

9️⃣ 错误处理与日志

  • 不要把数据库错误（堆栈、SQL 等）返回给用户端。返回友好且不泄漏细节的信息。
  • 在后端日志记录详细错误（含 SQL、参数、用户、时间），并限制日志访问权限。

10️⃣ 检测与测试（持续）

  • 静态代码扫描（SAST）检查原始字符串拼接、动态 SQL。
  • 动态测试（DAST）使用工具（如 sqlmap 等）对已部署应用做渗透测试。
  • 单元/集成测试中加入针对常见 SQL 注入 payload 的负面测试用例。
  • 在 CI 中引入安全扫描（例如检查是否使用参数化 API 等）。

11️⃣ 常见场景实战建议（快速清单）

  • 登录 / 认证：必须使用参数化查询。密码永远用哈希（bcrypt/argon2），不存明文/可逆密文。
  • 搜索 / 过滤：参数化值 + 白名单列名。对分页/limit 做范围限制（例如最大 100）。
  • 管理员功能：额外审计与多因素认证，限制来源 IP。
  • 报表 / 导出：使用只读账号连接副本数据库（read-only replica）。

12️⃣ 常见误区与陷阱

  • 误区：使用 addslashes() 或手工替换就足够 —— 不可靠。
  • 误区：仅在前端做输入校验 —— 前端可被绕过，必须在后端校验。
  • 陷阱：ORM 自动化不等于安全 —— 原生查询/拼接会破坏自动安全性。
  • 陷阱：认为 WAF 可以替代安全编码 —— WAF 是辅助手段，不是替代。

13️⃣ 示例攻击检测样例（用于监控/日志匹配）

  • 常见 payload 片段：' OR '1'='1, UNION SELECT, --, ; DROP TABLE, /*...*/, xp_cmdshell（MSSQL），information_schema 查询等。
  • 但记住：简单字符串匹配会产生误报，结合异常行为（错误、延迟、重复探测）更可靠。

14️⃣ 推荐快速行动计划（可直接执行）

  1. 全面代码审查：查找所有拼接 SQL 的位置并改造为参数化。
  2. 对用户可控的“列名/排序/分页”参数实现白名单。
  3. 在数据库层设置最小权限账号并禁用多语句。
  4. 部署或开启 WAF，设置规则并逐步调优以减少误报。
  5. 加入安全测试（CI 中 SAST + 定期 DAST/渗透）。
  6. 建立监控/告警：大量 UNION、' OR 等探测式请求触发报警。

15️⃣ 如果你要我帮忙（我可以立刻做的事）

  • 给你检查一段代码并改写成安全的参数化版本（Java/Python/PHP/C# 等）。
  • 给出你现有 API 的白名单校验模板（例如排序/列名/limit 的实现代码）。
  • 帮你写 CI 中的安全测试样例（含 sqlmap 自动化调用或 SAST 规则示例）。

告诉我你想要哪项（例如“检查项目中 login/auth 的代码并修复” 或 “给我一套用于 Node.js + Express 的注入防护模板”），我会马上给出具体可复制粘贴的代码和步骤。