如何防止SQL注入？

wen 网络安全 2026-07-21 4

如何防止SQL注入？深度防御策略与实战指南

目录导读

什么是SQL注入？它的危害有多严重？
为什么程序员会写出有注入漏洞的代码？
核心防御手段：参数化查询与预编译语句
进阶防护：输入验证、存储过程与ORM安全实践
WAF与数据库权限最小化原则
常见错误：为什么“转义”不等于安全
问答环节：开发者最关心的5个问题
构建多层防御体系

什么是SQL注入？它的危害有多严重？

SQL注入是一种通过将恶意SQL代码插入到Web表单输入或URL参数中，从而操纵后端数据库的攻击方式，攻击者可以利用该漏洞执行未授权的数据库查询,甚至获取整个服务器的控制权。

典型危害包括：

窃取用户数据（如信用卡号、密码哈希）
篡改数据库内容（如修改订单金额）
绕过认证（无需密码即可登录管理后台）
执行操作系统命令（在极端情况下获取服务器Shell）

真实案例： 2017年Equifax数据泄露事件中，攻击者正是通过一个已知的SQL注入漏洞获取了1.43亿用户的敏感信息。

为什么程序员会写出有注入漏洞的代码？

根本原因在于将用户输入直接拼接到SQL语句中。

# 错误示例：直接拼接字符串
query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"

当用户输入 admin' -- 时,SQL语句变为：

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

注释掉了密码验证部分,攻击者无需密码即可登录。

核心防御手段：参数化查询与预编译语句

这是防止SQL注入的最有效方法，没有之一。

概念： 让数据库引擎将SQL语句的结构与参数分开处理，用户输入仅作为“数据”传递给占位符,永远不会被解析为SQL代码。

示例（不同语言实现）：

Python (psycopg2):

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

Java (JDBC PreparedStatement):

PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE username = ? AND password = ?");
ps.setString(1, username);
ps.setString(2, password);

PHP (PDO):

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

为什么有效？ 因为数据库引擎在编译SQL时，参数位置被固定为占位符，后续传入的“数据”不会被解释为SQL关键字或运算符。

进阶防护：输入验证、存储过程与ORM安全实践

输入验证（第二道防线）

白名单验证：只接受预期格式的数据（如ID必须是整数）
黑名单过滤：禁止特殊字符，但不能依赖它作为唯一防护
长度限制：防范缓冲区溢出类攻击

存储过程（需谨慎使用）

虽然存储过程本身不防止注入，但如果结合参数化调用,则相当安全：

CREATE PROCEDURE GetUser
    @username NVARCHAR(50),
    @password NVARCHAR(50)
AS
BEGIN
    SELECT * FROM users WHERE username = @username AND password = @password
END

调用时仍要使用参数化方式传递参数。

ORM框架（如Hibernate、SQLAlchemy）

ORM通常自动使用参数化查询,但要注意：

避免使用原生SQL查询
警惕ORM中的“拼接函数”（如raw()或nativeQuery()）

WAF与数据库权限最小化原则

Web应用防火墙（WAF）

可以阻挡已知攻击模式（如SQL注入特征字符 ' OR 1=1--）
但不能替代代码层面的防护，因为攻击者可以绕过WAF规则

数据库权限最小化

Web应用连接数据库的账号绝不允许使用root或sa超级权限
只授予必要的操作权限：如只读SELECT，禁止DROP TABLE或INSERT（除非必要）
使用view限制可访问的列和行

常见错误：为什么“转义”不等于安全？

许多开发者误以为给字符串加反斜杠（mysql_real_escape_string）就安全了。这是危险的误解！

问题所在：

转义函数可能会被特定字符集绕过（如GBK编码的多字节字符攻击）
转义无法处理数值类型字段（如输入1 OR 1=1）
误以为addslashes()就足够（实际上它不适用于所有数据库）

转义只能作为临时补丁,永远不能替代参数化查询。

问答环节：开发者最关心的5个问题

Q1：我的项目是遗留系统，全部用拼接SQL，怎么低成本修复？

A：推荐使用数据库驱动提供的中间层拦截，例如MySQL Proxy或SQL解析工具,但长期必须重写为参数化查询。

Q2：有人说存储过程可以防止注入，真的吗？

A：不准确，如果存储过程内部仍使用字符串拼接用户输入，依然不安全，关键是将用户输入作为参数传递,而非拼接到SQL字符串中。

Q3：WAF能100%防护吗？

A：不能，WAF基于规则匹配，攻击者可以通过Base64编码、注释混淆和Unicode编码绕过，WAF是辅助手段,不是根本解决方案。

Q4：是否应该在所有SQL查询中使用参数化？包括IN语句？

A：是的，对于IN (?)这样的结构，可以使用数组展开或临时表技术，许多框架已支持：WHERE id IN (:ids),参数传入数组即可。

Q5：我的ORM框架已经自动处理了，还需要担心吗？

A：需要，不要使用ORM的“原生SQL”功能（如EntityManager.createNativeQuery()）,更不要在ORM查询中拼接字符串。

构建多层防御体系

防止SQL注入没有银弹，需要构建纵深防御：

第一层（根本）：所有数据库查询使用参数化查询/预编译语句
第二层（辅助）：严格的输入验证（白名单优先）
第三层（权限）：数据库账号最小权限原则
第四层（监控）：WAF + 数据库审计日志

核心原则：永远不要信任用户输入。 无论前端做了多少验证，后端必须坚持参数化查询，安全不是某个功能,而是一种设计思维。

最后一句：当你的代码中看不到任何拼接的SQL字符串时,你才真正站在了安全的一边。