SQL注入攻击的核心是利用应用程序对用户输入的处理漏洞，将恶意SQL片段拼接进正常查询语句中执行。要彻底防范这类攻击，不能只依靠单一手段，需要从代码层、配置层、架构层建立多层防护体系，消除不同环节的攻击入口。
一、代码层防御方案
代码层是防御SQL注入的第一道防线，核心思路是避免用户输入直接拼接进SQL语句，同时对输入内容进行严格校验。
1. 使用预编译语句（参数化查询）
预编译语句会让数据库先编译SQL模板，用户输入的内容仅作为参数传递，不会被解析为SQL语法的一部分，从根源上避免注入。以下是不同语言的实现示例：
Java示例（JDBC）
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
public class UserDao {
public User getUserById(Connection conn, int userId) throws Exception {
// SQL模板使用?作为占位符，用户输入不会参与SQL编译
String sql = "SELECT id, username FROM user WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
// 设置参数，数据库会自动处理特殊字符转义
ps.setInt(1, userId);
ResultSet rs = ps.executeQuery();
if (rs.next()) {
User user = new User();
user.setId(rs.getInt("id"));
user.setUsername(rs.getString("username"));
return user;
}
return null;
}
}
PHP示例（PDO）
<?php
function getUserInfo(PDO $pdo, $username) {
// 使用命名占位符:username
$sql = "SELECT id, email FROM user WHERE username = :username";
$stmt = $pdo->prepare($sql);
// 绑定参数，避免拼接
$stmt->bindParam(':username', $username, PDO::PARAM_STR);
$stmt->execute();
return $stmt->fetch(PDO::FETCH_ASSOC);
}
?>
2. 输入校验与过滤
对所有用户输入的内容进行类型、格式校验，拒绝不符合预期的内容。比如整数类型的参数强制转换为整数，邮箱、手机号等格式使用正则匹配校验。同时避免使用动态拼接表名、列名的逻辑，如果必须使用，需要建立白名单映射，禁止直接接收用户输入作为表名或列名。
3. 避免拼接SQL字符串
严禁使用字符串拼接的方式构造SQL语句，比如下面的写法存在严重注入风险，必须避免：
// 危险写法，禁止在代码中使用 String sql = "SELECT * FROM user WHERE username = '" + userInput + "'";
二、配置层防御方案
合理的服务配置可以进一步缩小攻击面，即使代码存在小漏洞，也能通过配置层降低被利用的概率。
1. 数据库权限最小化
给Web应用使用的数据库账号只分配必要的权限，比如只给查询、插入权限，禁止授予DROP、ALTER、FILE等高危权限，同时禁止该账号访问系统表和其他无关业务的数据库。如果应用只需要查询用户表，就只开放user表的SELECT权限，避免攻击者通过注入获取更高权限后操作其他数据。
2. 关闭数据库错误信息回显
生产环境不要将数据库的原始错误信息直接返回给用户，比如MySQL的错误提示会暴露表名、字段名等信息，攻击者可以利用这些信息构造更精准的注入语句。可以在应用层捕获数据库异常，返回统一的错误提示，比如"系统繁忙，请稍后再试"。
3. 启用数据库自身防护功能
部分数据库自带防注入的相关配置，比如MySQL可以开启sql_mode的严格模式，禁止不规范的SQL语法执行；PostgreSQL可以配置statement_timeout限制查询执行时间，避免注入后执行耗时过长的恶意查询。
三、架构层防御方案
架构层的防护是整体体系的最后一道屏障，即使前面两层被突破，也能通过架构设计拦截大部分攻击。
1. 部署Web应用防火墙（WAF）
在Web服务器和应用服务器之间部署WAF，配置SQL注入检测规则，识别常见的注入特征，比如union select、or 1=1、sleep()等恶意片段，直接拦截可疑请求。同时定期更新WAF规则库，应对新的注入攻击手法。
2. 使用ORM框架
优先使用成熟的ORM框架（如MyBatis、Hibernate、Django ORM等），这些框架内置了参数化查询、输入转义等安全机制，默认情况下可以避免大部分SQL注入问题。使用时注意遵循框架的安全使用规范，比如MyBatis中不要使用${}直接拼接参数，而是使用#{}进行参数绑定。
3. 数据访问层隔离
将数据库访问逻辑封装在独立的数据访问层，不允许业务逻辑层直接拼接SQL语句，所有数据库操作都通过数据访问层提供的接口完成，统一在数据访问层做安全校验和参数处理，避免安全逻辑分散在各个业务模块中遗漏。
4. 定期安全审计与渗透测试
定期使用SQL注入扫描工具检测应用接口，同时开展人工渗透测试，发现潜在的安全漏洞。对发现的漏洞及时修复，同时建立漏洞响应机制，确保新的攻击手法出现后能快速更新防护策略。
四、常见误区提醒
- 不要依赖前端输入校验，前端校验可以被绕过，所有校验必须在服务端完成
- 不要认为使用了预编译就绝对安全，如果预编译中仍然拼接了用户输入作为SQL的一部分，依然存在注入风险
- 不要忽略日志审计，定期查看数据库操作日志和Web访问日志，发现异常的查询行为及时处理
SQL注入的防御是一个持续的过程，需要结合代码规范、配置优化、架构设计共同推进，建立多层防护体系才能最大程度降低安全风险，保障应用和数据的安全。