一、SQL 注入存在条件

二、JDBC 框架 SQL 注入分析

（一）危险用法：Statement

• 原理：通过字符串拼接的方式构造 SQL 语句，没有预编译机制。当用户可控的输入未经过滤直接拼接到 SQL 语句中时，攻击者可以篡改 SQL 逻辑，实现注入攻击。
• 示例代码：

// Web接口场景
@RequestMapping("/jdbc/vuln")
public String jdbc_sqli_vul(@RequestParam("username") String username) {
    String sql = "select * from users where username = '" + username + "'";
    Statement statement = con.createStatement();
    ResultSet rs = statement.executeQuery(sql);
    return "查询结果";
}

• 漏洞验证：当输入joychou' or '1'='1时，生成的 SQL 语句为select * from users where username = 'joychou' or '1'='1'，该语句会返回全部用户数据，造成信息泄露。

（二）安全用法：PreparedStatement

• 原理：采用预编译机制，使用?作为占位符，通过setXxx()方法绑定参数。这种方式会将用户输入作为数据处理，而不是 SQL 语句的一部分，因此无法改变 SQL 结构，能有效防止注入。
• 示例代码：

String sql = "select * from users where username = ?";
PreparedStatement st = con.prepareStatement(sql);
st.setString(1, username);
ResultSet rs = st.executeQuery();

• 优势：不仅能防止 SQL 注入，还能减少 SQL 语句的重复编译，提升系统性能。

（三）高频漏洞场景

三、MyBatis 框架 SQL 注入分析

（一）核心风险点：#{} 与 ${}

（二）高频漏洞场景

1. 模糊查询

• 危险用法：由于like '%#{param}%'存在语法错误，很多开发者会改用${ }进行拼接，从而引入风险：

<select id="findByUserNameVuln" resultType="User">
    select * from users where username like '%${_parameter}%'
</select>

• 安全用法：使用数据库函数实现预编译，避免直接拼接：

<select id="findByUserNameSec" resultType="User">
    select * from users where username like concat('%', #{_parameter}, '%')
</select>

2. in多值查询

• 危险用法：直接用${ }拼接in语句，会导致注入风险：

<select id="findByUserNameVuln04" resultType="User">
    select * from users where id in (${id})
</select>

• 安全用法：使用foreach循环生成占位符，实现参数绑定：

<select id="selectBookByIds" parameterType="list" resultType="Book">
    SELECT * FROM Book WHERE id IN
    <foreach collection="list" item="id" open="(" separator="," close=")">
        #{id}
    </foreach>
</select>

3. order by排序

• 危险用法：因为#{ }会给字段加引号，导致排序失效，所以错误地使用${ }进行拼接：

<select id="getUsersBySort" resultType="User">
    SELECT * FROM users ORDER BY ${sortColumn}
</select>

• 安全用法：可以采用字段列数预编译的方式，或者严格过滤字段名，只允许白名单中的字段参与排序。

（三）实战审计案例

1. 审计入口：在 Mapper 文件中搜索${关键字，定位可能存在风险的代码位置。
2. 漏洞代码：发现存在SELECT distinct ${column} FROM users这样的代码，其中column由路由参数传入，攻击者可以控制该参数。
3. 验证 Payload：通过访问http://xxx/option/users/(select%20database())，成功获取到数据库名，证实了 SQL 注入漏洞的存在。

四、MyBatis-Plus 框架 SQL 注入分析

（一）安全机制

@RequestMapping("/like")
public List<Tutorial> mybatislike(String author) {
    QueryWrapper<Tutorial> wrapper = new QueryWrapper<>();
    wrapper.like("author", author); 
    return tutorialMapper.selectList(wrapper);
}

（二）高频漏洞场景

（三）自定义 SQL 风险

五、Hibernate/JPA 框架 SQL 注入分析

（一）危险用法

• HQL 注入示例：

String userInput = "2 or 1=1";
String hql = "from Book where id = " + userInput;
Query<Book> query = session.createQuery(hql, Book.class);
Book book = query.uniqueResult();

• 原生 SQL 注入示例：

String sql = "select * from user where username = '" + username + "'";
Query<People> query = session.createNativeQuery(sql);

（二）安全用法

（三）HQL 注入限制

• 不支持UNION SELECT语句；
• 无法访问系统表；
• 需要知晓实体类的字段名才能进行有效的注入；
• 不支持--注释，部分情况下支持/* comment */注释。