SQL注入漏洞怎样修复？

本文目录导读：

1. 最根本的修复：使用参数化查询（Prepared Statement）
2. 辅助但重要的修复：输入验证与过滤
3. 数据库权限最小化原则
4. 存储过程（Stored Procedure）的正确使用
5. 其他防御层（纵深防御）
6. 如何检测是否已修复？
7. 总结与行动清单

SQL注入漏洞的修复需要从代码层面、数据库层面和运维层面多管齐下，最核心的原则是：永远不要信任用户的任何输入，并且将数据与代码严格分离。

以下是具体的修复方案,按推荐优先级排序：

最根本的修复：使用参数化查询（Prepared Statement）

这是防御SQL注入最有效、最推荐的方法，它强迫SQL语句的逻辑结构（代码）与用户提供的数据（参数）分离，数据库引擎会明确知道哪部分是命令，哪部分是数据，从而杜绝注入。

• Java (JDBC)：

  // 错误：拼接字符串
  // String sql = "SELECT * FROM users WHERE username = '" + username + "'";
  // 正确：使用 ? 占位符
  String sql = "SELECT * FROM users WHERE username = ?";
  PreparedStatement pstmt = connection.prepareStatement(sql);
  pstmt.setString(1, username); // 传入用户输入
  ResultSet rs = pstmt.executeQuery();

• PHP (PDO)：

  // 错误：拼接字符串
  // $sql = "SELECT * FROM users WHERE username = '" . $username . "'";
  // 正确：使用命名参数或问号
  $stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
  $stmt->execute(['username' => $username]);

• Python (sqlite3 / psycopg2)：

  # 错误：f-string 或 % 格式化
  # cursor.execute(f"SELECT * FROM users WHERE username = '{username}'")
  # 正确：使用 ? 占位符
  cursor.execute("SELECT * FROM users WHERE username = ?", (username,))
  # 或使用 %s (PostgreSQL)
  cursor.execute("SELECT * FROM users WHERE username = %s", (username,))

• C# (.NET)：

  // 错误：拼接字符串
  // string sql = "SELECT * FROM users WHERE username = '" + username + "'";
  // 正确：使用 SqlParameter
  using (SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE username = @username", conn))
  {
      cmd.Parameters.AddWithValue("@username", username);
      // 执行...
  }

辅助但重要的修复：输入验证与过滤

参数化查询解决了绝大多数注入问题,但永远不要完全依赖过滤作为唯一手段，过滤应作为辅助，用于业务逻辑校验（如邮箱格式、数字范围）。

• 白名单验证（推荐）： 只接受符合预期格式的数据，ID 必须是整数，邮箱必须包含 @。
• 黑名单过滤（不推荐）： 尝试屏蔽 , , SELECT, DROP 等关键字，攻击者可以使用编码、注释符 、大小写混合等方式绕过，极易出错。

数据库权限最小化原则

即使发生了注入,通过限制数据库用户的权限可以大大降低损失。

• 不要使用高权限账号（如 root, sa, dbo）： 应用程序连接数据库时，使用一个独立的、低权限的账号。
• 遵循最小权限原则：
  • 对于查询操作，只给 SELECT 权限。
  • 对于修改操作，只给 INSERT、UPDATE、DELETE 权限。
  • 禁止给普通应用账户 CREATE、ALTER、DROP、GRANT 等 DDL 权限，这样即使注入 DROP TABLE users，也会因为无权限而失败。

存储过程（Stored Procedure）的正确使用

存储过程本身不一定是安全的，如果在存储过程内部仍然拼接 SQL 字符串，同样会被注入。

• 正确做法： 在存储过程内部也使用参数化输入。
• 错误例子： 创建一个存储过程 sp_getUser @username，但在内部执行 EXEC('SELECT * FROM users WHERE username = ''' + @username + '''')。

其他防御层（纵深防御）

• ORM（对象关系映射）框架： 使用 Hibernate、Entity Framework、Django ORM、SQLAlchemy 等现代 ORM 框架，它们默认使用参数化查询，能极大减少手动写 SQL 的风险。
• Web 应用防火墙（WAF）： 部署 WAF (如 ModSecurity, AWS WAF, Cloudflare WAF) 作为流量过滤层，它可以拦截常见的 SQL 注入攻击载荷，但不能完全取代代码层面的修复。
• 转义（Escape）： 在无法使用参数化查询的特殊场景（如动态表名、ORDER BY 字段名），需要对输入进行严格转义。注意： 表名和字段名无法参数化，必须使用白名单验证。
• 隐藏错误信息： 在生产环境中，关闭详细的数据库错误输出，攻击者常通过错误信息（如 You have an error in your SQL syntax...）来推断数据库结构和列名。

如何检测是否已修复？

1. 代码审计： 全局搜索项目中所有拼接 SQL 的地方（字符串连接 , , CONCAT, 等）。
2. 静态分析工具： 使用 SonarQube, FindBugs, Fortify 等工具扫描代码。
3. 动态测试（渗透测试）： 在测试环境输入以下经典 payload 尝试注入：
   • ' OR 1=1 -- (尝试绕过登录)
   • '; DROP TABLE users; -- (尝试执行危险命令)
   • ' UNION SELECT 1,2,3 -- (尝试获取额外数据)

总结与行动清单

一句话建议： 立即对全站代码进行搜索，将所有 WHERE username = '"+变量+"' 改为 WHERE username = ? 并绑定变量。