IT技术社区_专业开发者平台_最新编程教程与解决方案 -沐辰社区

Java案例怎么防止SQL注入？

wen java案例 12

Java案例详解：如何有效防止SQL注入攻击？——从原理到实战的完整指南

Java案例怎么防止SQL注入？

目录导读

  1. SQL注入的本质与危害

    什么是SQL注入？攻击者如何通过输入篡改SQL语句？

  2. Java开发中常见的SQL注入漏洞场景

    字符串拼接、动态查询、预处理失效等典型案例

  3. 核心防护手段：参数化查询（PreparedStatement）

    原理对比、代码示例、为什么它能彻底杜绝注入？

  4. 进阶防御：ORM框架（MyBatis/JPA）的安全写法

    • {}与${}的区别、避免动态拼接陷阱

  5. 其他关键安全措施

    输入验证、最小权限原则、存储过程、错误信息处理

  6. 实战案例：从漏洞代码到安全重构

    原始有漏洞的登录模块 → 改造为安全版本

  7. 常见问答（FAQ）

    针对开发者最困惑的10个问题逐一解答

  8. 总结与最佳实践清单

SQL注入的本质与危害

1 什么是SQL注入？

SQL注入（SQL Injection）是指攻击者通过在应用程序的输入参数中插入恶意的SQL代码，使得原本只执行查询的SQL语句被篡改为具有破坏性的指令,一个简单的登录查询：

SELECT * FROM users WHERE username='admin' AND password='123456';

如果攻击者在username字段输入：admin' OR '1'='1,则SQL变为：

SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='anything';

由于'1'='1'永远为真,攻击者无需正确密码即可登录系统。

2 危害有多严重？

  • 数据泄露：获取所有用户密码、信用卡信息、商业机密。
  • 数据篡改：删除、修改数据库记录,甚至植入恶意数据。
  • 权限提升：从普通用户权限提升为数据库管理员,控制整个服务器。
  • 服务瘫痪：通过DROP TABLE等命令直接摧毁数据库。

真实案例： 2014年某电商平台因SQL注入导致8300万用户数据泄露,直接经济损失超2亿美元。

Java开发中常见的SQL注入漏洞场景

1 危险的字符串拼接（最普遍）

String sql = "SELECT * FROM users WHERE username='" + userName + "' AND password='" + password + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

只要userName或password包含单引号、分号、注释符等,攻击者就可注入。

2 动态ORDER BY / LIMIT 等非占位符场景

有些开发者以为只有WHERE子句才危险，其实ORDER BY、表名、列名同样风险：

String sql = "SELECT * FROM products ORDER BY " + sortColumn;

如果sortColumn被注入id; DROP TABLE products;--,后果灾难。

3 使用“安全”函数但仍拼接

例如使用replace()过滤单引号，但攻击者可利用转义、宽字节注入绕过。

核心防护手段：参数化查询（PreparedStatement）

1 原理说明

PreparedStatement预编译机制：先将SQL语句结构发送给数据库编译，再将参数作为纯数据传递，这意味着参数无论如何都无法改变SQL语法结构，即使参数中包含' OR 1=1 --，它也会被整体当作一个字符串值处理,而非SQL指令。

2 代码示例

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, userName);  // 参数自动转义
pstmt.setString(2, password);
ResultSet rs = pstmt.executeQuery();

关键点： 使用占位符,不要拼接任何用户输入到SQL字符串中。

3 为什么它能彻底杜绝？

  • 数据库引擎预先解析SQL语句结构,后续参数不参与语法解析。
  • 自动处理特殊字符转义,无需手动过滤。
  • 性能更优（预编译可缓存执行计划）。

进阶防御：ORM框架的安全写法

1 MyBatis：#{} vs ${}

<!-- 安全写法：#{} 自动参数化 -->
<select id="getUser" resultType="User">
  SELECT * FROM users WHERE username = #{userName}
</select>
<!-- 极度危险：${} 直接拼接字符串 -->
<select id="getUserByDynamicColumn">
  SELECT * FROM users ORDER BY ${sortColumn}
</select>

规则： 99%的情况下使用，只有表名、列名等数据库对象名才用（且必须白名单校验）。

2 Hibernate/JPA

// 安全：JPQL使用命名参数
Query query = entityManager.createQuery("FROM User u WHERE u.name = :name");
query.setParameter("name", userName);
// 危险：拼接JPQL
Query query = entityManager.createQuery("FROM User u WHERE u.name = '" + userName + "'");

其他关键安全措施

1 输入验证（第二道防线）

  • 白名单验证：只允许特定字符集（如UUID、数字、字母组合）。
  • 类型校验：如id字段强制为整数类型,阻止字符串注入。

2 最小权限原则

  • 应用程序数据库账户仅授予必要权限：如SELECT、INSERT，禁止DROP、ALTER。
  • 即使注入成功,也无法执行破坏性操作。

3 存储过程（谨慎使用）

虽然存储过程可封装逻辑，但如果内部仍使用动态SQL拼接，同样危险,只有参数化存储过程才安全。

4 错误信息处理

  • 不要在页面或日志中暴露原始SQL错误信息。
  • 自定错误提示，“系统繁忙，请稍后重试”。

实战案例：从漏洞代码到安全重构

1 原始有漏洞的登录模块

public boolean login(String username, String password) {
    String sql = "SELECT COUNT(*) FROM users WHERE username='" + username + 
                 "' AND password='" + password + "'";
    try (Statement stmt = connection.createStatement();
         ResultSet rs = stmt.executeQuery(sql)) {
        rs.next();
        return rs.getInt(1) > 0;
    }
}

攻击测试： 输入username = "admin'--"，SQL变为SELECT COUNT(*) FROM users WHERE username='admin'--' AND password='xxx',直接绕过密码验证。

2 安全重构版本

public boolean login(String username, String password) {
    String sql = "SELECT COUNT(*) FROM users WHERE username = ? AND password = ?";
    try (PreparedStatement pstmt = connection.prepareStatement(sql)) {
        pstmt.setString(1, username);
        pstmt.setString(2, password);
        try (ResultSet rs = pstmt.executeQuery()) {
            rs.next();
            return rs.getInt(1) > 0;
        }
    }
}

额外加强： 结合白名单验证，限制username仅包含字母数字和下划线。

常见问答（FAQ）

Q1：所有SQL注入漏洞都能用PreparedStatement解决吗？

A： 是的，只要SQL语句结构固定（参数化查询可覆盖绝大部分场景），但ORDER BY、表名等非参数化场景仍需白名单校验。

Q2：MyBatis中什么时候可以用${}？

A： 只有当你需要动态拼接数据库对象名（如表名、列名）时，且必须硬编码白名单过滤，

if (!"id, name, age".contains(sortColumn)) {
    throw new IllegalArgumentException("Invalid sort column");
}

Q3：使用ORM框架（如JPA）就自动安全了吗？

A： 不！取决于写法，使用@Query注解时如果拼接?1和原生SQL字符串，依然存在风险，必须使用param或?1绑定参数。

Q4：能不能用正则过滤特殊字符来防注入？

A： 不推荐作为主要手段，攻击方式不断演化（Unicode编码、注释混用等），正则容易遗漏,参数化查询才是根本。

Q5：数据库连接池（如HikariCP）会影响安全性吗？

A： 不影响，连接池只管理连接复用,不改变SQL执行方式。

Q6：如何检测现有代码是否存在注入漏洞？

A： 使用静态代码分析工具（如FindBugs、SonarQube）扫描Statement和字符串拼接模式，也可用OWASP ZAP进行渗透测试。

Q7：Integer类型的参数也需要参数化吗？

A： 是的，虽然数字类型注入难度大，但使用参数化查询是统一规范,避免未来代码改动引入风险。

Q8：存储过程是否绝对安全？

A： 不一定，如果存储过程内部使用EXEC (@sql)动态执行拼接的SQL，同样危险,参数化存储过程才安全。

Q9：如何防止ORDER BY注入？

A： 使用白名单映射，例如前端传sort=1，后端转换为ORDER BY create_time,而不是直接拼接字段名。

Q10：是否还需要做输入转义如escapeHtml？

A： 防止SQL注入不需要（参数化已处理），但为防止XSS攻击需要,这是另一个安全维度。

总结与最佳实践清单

核心原则

  • 永远使用参数化查询（PreparedStatement或ORM的/param）。
  • 绝不使用字符串拼接构建SQL（即使是防御过的字符串）。
  • 最小权限原则：应用数据库账户只给必要权限。
  • 输入验证作为第二道防线：类型、长度、白名单。

最终行动清单

  1. ✅ 团队代码审查：查找所有Statement和字符串拼接的SQL。
  2. ✅ 替换为PreparedStatement或ORM安全写法。
  3. ✅ 添加预提交CI检查（如SonarQube规则：Avoid use of Statement）。
  4. ✅ 培训研发人员：SQL注入原理与安全编码规范。
  5. ✅ 上线前渗透测试：使用SQLMap工具验证修复效果。

安全没有“银弹”，但遵循上述措施，你可以将SQL注入风险降低到近乎为零。 每一个被注入的数据库，背后都有一个没使用PreparedStatement的开发者，从今天起，为自己的代码加上这道“安全锁”。

上一篇Java案例如何使用预处理对象？

下一篇Java案例如何处理数据库事务？

相关文章

抱歉，评论功能暂时关闭!