一、什么是SQL注入？它为什么这么危险？
简单来说，SQL注入就是攻击者利用我们程序拼接SQL语句时的疏忽，把一些恶意的SQL代码“注入”到正常的查询语句中。这样一来，数据库就会执行这些额外的恶意指令。
举个例子，我们有一个简单的登录功能，代码里可能会这样写（这是一个反面教材）：
// 技术栈：Java + JDBC (这是一个危险示例！)
String username = request.getParameter("username"); // 用户输入
String password = request.getParameter("password"); // 用户输入
// 危险操作：直接拼接用户输入到SQL语句中
String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);
if (rs.next()) {
// 登录成功
}
看起来很正常对吧？但如果用户在用户名输入框里填的不是“张三”，而是 admin' -- 呢？拼接出来的SQL语句就变成了：
SELECT * FROM users WHERE username = 'admin' --' AND password = '随便什么密码'
在SQL中，-- 是注释符号，它会把后面的语句都注释掉。于是，这个查询就变成了“查找用户名为admin的用户”，完全绕过了密码验证！攻击者就这样轻松以管理员身份登录了。
更危险的，攻击者可能输入 ‘; DROP TABLE users; --，如果你的数据库权限够大，整个用户表可能就没了。所以，SQL注入的危害包括：数据泄露、数据篡改、数据删除，甚至可能导致攻击者获取服务器控制权。我们必须从源头——编码实践上杜绝它。
二、防御之道一：使用预编译语句（PreparedStatement）
这是防止SQL注入的首选方案，也是最有效、最推荐的方法。它的原理是：让SQL语句的“结构”和“数据”分家。
工作原理：我们先把SQL语句的框架写好，比如 SELECT * FROM users WHERE username = ? AND password = ?，这里的 ? 是一个占位符。数据库会先对这个框架进行编译和优化，确定它的执行计划。之后，我们再传入具体的参数值（如“张三”、“123456”）给这些占位符。因为传入的值只被当作“数据”来处理，而不会被当作SQL代码的一部分来解析，所以无论数据里包含什么特殊字符（如单引号、分号），都无法改变原SQL语句的结构。
让我们用代码来感受一下它的安全与优雅：
// 技术栈：Java + JDBC
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
public class LoginService {
public boolean safeLogin(String inputUsername, String inputPassword) {
String url = "jdbc:mysql://localhost:3306/mydb";
String dbUser = "root";
String dbPass = "password";
// 正确的SQL语句，使用 ? 作为参数占位符
String sql = "SELECT id, username FROM users WHERE username = ? AND password = ?";
try (Connection conn = DriverManager.getConnection(url, dbUser, dbPass);
// 重点：创建 PreparedStatement 对象，此时SQL已发送到数据库进行预编译
PreparedStatement pstmt = conn.prepareStatement(sql)) {
// 为预编译语句中的占位符设置参数
// 第一个参数‘1’表示第一个问号，第二个参数是我们要传入的值
pstmt.setString(1, inputUsername); // 安全地设置用户名
pstmt.setString(2, inputPassword); // 安全地设置密码
// 执行查询，这里不需要再传入SQL字符串
try (ResultSet rs = pstmt.executeQuery()) {
// 如果查询有结果，说明用户名密码匹配
return rs.next();
}
} catch (Exception e) {
e.printStackTrace();
return false;
}
}
}
优点：
- 绝对安全：从根本上杜绝了SQL注入。
- 性能更好：同一条预编译语句（仅参数不同）可以重复使用，数据库无需多次编译，提高了效率。
- 代码清晰：将SQL逻辑与数据分离，更易于阅读和维护。
注意事项：预编译语句并非“银弹”，它只能保护用 ? 占位符传入的数据。绝对不能用字符串拼接的方式生成部分SQL语句后再交给 PreparedStatement，比如 String sql = “SELECT * FROM ” + tableName + “ WHERE id = ?”; 这里的 tableName 如果来自用户输入，依然存在风险。对于表名、列名等SQL标识符，不能使用占位符，必须进行严格的过滤。
三、防御之道二：使用ORM框架（如MyBatis, Hibernate）
对于现代Java应用，我们很少直接写JDBC代码，更多是使用ORM框架。它们底层也使用预编译语句，但提供了更便捷的操作方式。这里以最常用的MyBatis为例。
在MyBatis中，我们主要使用 #{} 语法来防止注入。#{} 在底层会被转换为预编译语句的 ?。
<!-- 技术栈：Java + MyBatis -->
<!-- UserMapper.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.example.mapper.UserMapper">
<!-- 安全查询：使用 #{} 语法 -->
<select id="selectUserByLogin" resultType="com.example.model.User">
SELECT id, username, email
FROM users
WHERE username = #{username} <!-- MyBatis会将其处理为预编译参数 -->
AND password = #{password}
</select>
<!-- 危险示例：使用 ${} 进行字符串拼接（应避免！） -->
<select id="dangerousSelect" resultType="com.example.model.User">
SELECT * FROM users ORDER BY ${columnName}
<!-- 如果columnName来自用户输入，例如“id; DROP TABLE users; --”，将导致注入！ -->
<!-- ${} 是直接拼接，仅用于可信的、非用户输入的场景，如动态排序字段（但需在代码层做枚举校验） -->
</select>
</mapper>
对应的Java接口和调用：
// UserMapper.java
package com.example.mapper;
import com.example.model.User;
import org.apache.ibatis.annotations.Param;
public interface UserMapper {
User selectUserByLogin(@Param("username") String username, @Param("password") String password);
}
// 调用层
@Autowired
private UserMapper userMapper;
public User login(String username, String password) {
// 此行调用是安全的，因为MyBatis在底层使用了PreparedStatement
return userMapper.selectUserByLogin(username, password);
}
关联技术详解：这里要重点区分MyBatis中 #{} 和 ${} 的天壤之别。
#{}：安全。是参数占位符，会被预处理为?，能防止SQL注入。${}：不安全。是字符串替换，直接将传入的值拼接到SQL语句中。除非你能百分百确定参数内容是安全且非用户可控的（例如，从一个固定的枚举值中选择），否则绝对不要用${}来拼接用户输入。
ORM框架的优缺点：
- 优点：开发效率高；内置了预编译等安全机制；减少大量样板代码。
- 缺点：需要学习框架本身；复杂的查询可能不如手写SQL直观；性能调优需要了解框架原理。
四、防御之道三：严格的输入验证与过滤
虽然预编译是治本之策，但“输入验证”作为安全的第一道防线同样不可或缺。其核心思想是：不相信任何来自外部的输入。
验证应该在两个层面进行：
- 业务逻辑层面：检查数据是否符合业务规则。例如，用户名是否只允许字母数字，长度是否在3-20字符之间。
- 安全层面：即使业务上允许某些特殊字符，在拼接进SQL前，也要考虑是否有风险。不过，切记，输入验证只能是辅助手段，绝不能替代预编译语句。
// 技术栈：Java (Spring Boot 示例)
import org.springframework.util.StringUtils;
import java.util.regex.Pattern;
public class UserInputValidator {
// 示例1：白名单验证 - 只允许字母数字
private static final Pattern USERNAME_PATTERN = Pattern.compile("^[a-zA-Z0-9]{3,20}$");
public static boolean isValidUsername(String username) {
if (!StringUtils.hasText(username)) {
return false;
}
return USERNAME_PATTERN.matcher(username).matches(); // 符合规则才返回true
}
// 示例2：黑名单过滤 - 移除或转义潜在危险字符（谨慎使用，不推荐作为主要防御）
// 注意：这种方法很容易被绕过，例如用“OR 1=1”的变体“OR 2=2”
public static String weakFilter(String input) {
if (input == null) {
return null;
}
// 这是一个非常简陋且不安全的示例，仅用于说明思想
// 实际上，单引号在预编译中无需过滤，而“OR”、“--”等可能是合法数据的一部分
String filtered = input.replace("'", "''"); // 在某些数据库中用两个单引号转义一个
filtered = filtered.replace("--", "");
filtered = filtered.replace(";", "");
return filtered;
}
// 在业务逻辑中使用验证
public void handleUserRegistration(String username, String email) {
if (!isValidUsername(username)) {
throw new IllegalArgumentException("用户名格式非法！");
}
// 继续处理，但最终写入数据库时，依然要使用PreparedStatement或MyBatis的#{}
}
}
注意事项：
- 优先使用白名单：定义允许的字符集合，比定义不允许的（黑名单）要安全得多，因为总有意想不到的绕过方式。
- 验证需在服务端进行：前端（JavaScript）验证是为了用户体验，可以轻松被绕过，服务端验证才是保证安全的底线。
- 不要依赖过滤来防止注入：正如代码注释所说，过滤（尤其是黑名单）非常脆弱。它应该与预编译语句结合，作为一种深度防御策略，而不是唯一策略。
五、应用场景与总结
应用场景： 本文讨论的安全实践适用于所有涉及数据库交互的Java应用场景，无论是传统的Servlet/JSP项目、Spring MVC应用、Spring Boot微服务，还是使用任何ORM框架（JPA, Hibernate, MyBatis, MyBatis-Plus等）的应用。只要你的代码需要执行SQL，就需要考虑SQL注入防护。
技术优缺点回顾：
- 预编译语句（PreparedStatement）：优点是最安全、性能好，是基石。缺点是需要开发者手动编写，略显繁琐。
- ORM框架：优点是提升开发效率，内置安全机制。缺点是需要学习成本，过度依赖可能导致对底层SQL失去控制。
- 输入验证：优点是良好的编程习惯，能拦截非法数据，提升系统健壮性。缺点是不能单独作为防注入手段，需与其他方法结合。
核心注意事项（务必牢记）：
- 永远不要拼接用户输入来构造SQL语句。这是万恶之源。
- 首选预编译语句（或ORM框架的
#{}），这是防注入的“金科玉律”。 - 正确使用ORM框架，明确区分
#{}（安全）和${}（危险）。 - 实施严格的、服务端的输入验证，作为辅助防御层。
- 最小权限原则：连接数据库的账号，不应该拥有
DROP,DELETE等高危权限，按需分配，即使被注入也能限制破坏范围。 - 日志与监控：记录异常的SQL请求参数，便于发现和追溯攻击行为。
文章总结： 解决SQL注入问题，技术上并不复杂，关键在于开发者的安全意识与编码习惯。记住一个简单的原则：“数据”永远是数据，不要让它有机会变成“代码”。通过坚持使用预编译语句、善用现代ORM框架的安全特性、并辅以严格的输入验证，我们就能构建出坚固的数据访问层，让SQL注入漏洞无处遁形。安全无小事，从每一行代码做起。
评论