如何编写SQL注入防护单元测试-SQL-PHP中文网

SQL注入防护单元测试应验证防护逻辑是否在关键路径生效，重点测恶意输入拦截、参数化查询调用、错误信息不泄露；须用真实输入触发SQL构建，避免绕过解析层或测试假防护。

如何编写sql注入防护单元测试

SQL注入防护单元测试该测什么

不是测“系统有没有被黑”，而是测你写的防护逻辑是否在关键路径上真正起效。重点验证三类行为：输入含 ' OR 1=1-- 这类恶意片段时，是否被拦截或安全转义；参数化查询是否被正确调用；以及错误信息是否泄露数据库结构（比如抛出 MySQLSyntaxErrorException 或 PSQLException）。

常见错误现象：测试只 mock 了 DAO 层返回值，却没传真实恶意字符串进 service 方法；或者用 PreparedStatement 构造 SQL 但拼接了用户输入——这种写法本身已违规，测试却通过，属于“测了假防护”。

必须用真实输入字符串触发实际 SQL 构建逻辑（哪怕底层是 MyBatis 或 JPA），不能绕过解析层
对使用 String.format、+ 拼接 SQL 的旧代码，测试要能捕获运行时异常或非法查询日志
若用 Hibernate，需确认 @Param 注解或 TypedQuery 参数绑定方式，而非 createNativeQuery + 字符串拼接

JUnit 5 中模拟恶意输入并验证异常路径

直接传 "admin'--" 进登录方法，看是否抛出预期的业务异常（如 IllegalArgumentException），而不是数据库异常。这说明你的校验层（如正则过滤、白名单检查）生效了；如果抛出 SQLException，说明防护没拦住，已进入 DB 执行阶段。

示例（Spring Boot + JUnit 5）：

@Test
void whenUsernameContainsSqlComment_thenThrowsIllegalArgumentException() {
    String malicious = "admin'--";
    assertThatThrownBy(() -> userService.findByUsername(malicious))
        .isInstanceOf(IllegalArgumentException.class)
        .hasMessageContaining("invalid characters");
}

注意：不要 assert “不抛异常”，而要 assert “抛指定异常”。因为很多框架默认允许单引号，仅靠数据库驱动的语法校验不可靠，且不同方言响应不一致（PostgreSQL 可能静默截断，MySQL 直接报错）。

避免用 @Sql 或内存数据库执行真实 SQL——那测的是 DB 防御能力，不是你的代码
若业务逻辑中调用了 Statement.executeQuery，测试必须覆盖该分支，并验证其输入是否经 PreparedStatement 包装
对前端传来的 JSON，测试应包含 raw body 含 \u0027（URL 编码单引号）等变体，确认解码后仍被拦截

MyBatis 场景下验证 #{} 与 ${} 的使用是否合规

#{} 是安全的占位符，${} 是字符串替换，后者等于把门打开。单元测试必须明确识别并拒绝任何含 ${} 的动态 SQL 使用，尤其在 order by、表名、字段名等无法参数化的场景。

Playabl

Playabl是一款AI文本写作工具，AI 原生游戏创作平台，用户生成游戏的 TikTok。

下载

实操建议：

在测试资源目录放一个扫描脚本（如 Python 或 Shell），遍历所有 *.xml 文件 grep \$\{，失败时 fail build——这不是单元测试，但必须和 UT 同步执行
对使用 ${tableName} 的 mapper 方法，写测试强制传入 "users; DROP TABLE users--"，验证是否抛出 RuntimeException 或被中间件（如 ShardingSphere）拦截
MyBatis-Plus 的 QueryWrapper 若调用 eq("name", userProvidedValue) 是安全的；但若用 apply("name = {0}", userInput) 就等同于 ${}，测试需覆盖该 case

容易被忽略的边界：ORM 懒加载 + HQL 注入

JPA/Hibernate 的 @Query 如果拼接了用户输入，即使用了 ? 占位符，也可能因懒加载触发二次查询而暴露漏洞。例如：用户传入 "1 or 1=1" 作为 ID，service 返回实体后，前端调用 user.getOrders().size() 触发 SELECT * FROM orders WHERE user_id = 1 or 1=1。

这类问题不会在单个 DAO 测试里暴露，必须构造完整链路：

测试方法需调用 service 层返回实体，再访问其关联集合属性，观察生成的 SQL 是否含原始输入
启用 spring.jpa.show-sql=true 并捕获 org.hibernate.SQL 日志，断言 SQL 字符串不含用户输入原文
对 @Query(value = "SELECT * FROM users WHERE id = ?1", nativeQuery = true)，?1 必须是 Long/Integer 类型，若传 String 且未校验格式，可能绕过类型转换直接拼入 SQL

最麻烦的不是写测试，是让团队接受：所有接收外部输入的入口点，都得有对应 UT 覆盖恶意字符串。漏掉一个 PathVariable 或 RequestParam，整套防护就形同虚设。