Java SQL 注入漏洞审计工具

分析 Java Web 项目源码，识别 SQL 操作实现，检测 SQL 注入漏洞风险。

漏洞分级标准

详见 SEVERITY_RATING.md

漏洞编号格式: {C/H/M/L}-SQL-{序号}
严重等级 = f(可达性 R, 影响范围 I, 利用复杂度 C)
Score = R × 0.40 + I × 0.35 + C × 0.25，映射 CVSS 3.1

核心要求

此技能必须完整分析所有 SQL 相关代码，不允许省略。

✅ 识别所有 SQL 执行入口点（JDBC/MyBatis/Hibernate）
✅ 分析每个 SQL 操作的参数化情况
✅ 检测所有潜在的 SQL 注入模式
✅ 为每个风险点提供验证 PoC
❌ 禁止省略任何 SQL 操作
❌ 禁止跳过反编译步骤

禁止省略规则（强制）

报告中的所有列表和表格必须完整输出，禁止使用任何形式的省略：

禁止写法	正确做法
`{...省略...}`	完整列出所有条目
`... (其他N个)`	完整列出所有条目
`等等` / `etc.`	完整列出所有条目
`以此类推`	完整列出所有条目
`更多见xxx`	在当前位置完整列出

示例 - 错误写法：

| # | 方法名 | 说明 |
|---|--------|------|
| 1 | getCommonQuery | 通用查询 |
| 2 | getCollisionQuery | 碰撞查询 |
|{...省略...}| ... | ... |    ← ❌ 禁止

示例 - 正确写法：

| # | 方法名 | 说明 |
|---|--------|------|
| 1 | getCommonQuery | 通用查询 |
| 2 | getCollisionQuery | 碰撞查询 |
| 3 | getIntervalQuery | 区间查询 |
| ... | ... | ... |
| 23 | getNewStaypointQuery | 新停留点查询 |    ← ✅ 完整列出

必须完整列出的内容：

受影响的方法列表
SQL 操作映射表
漏洞详情列表
参数列表
验证 Payload 列表

技能协作流程（CRITICAL）

java-sql-audit 应在 java-route-mapper 之后执行，基于已梳理的路由信息进行审计。

┌─────────────────────────────────────────────────────────────────┐
│                    完整审计流程                                  │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  [步骤1] java-route-mapper                                      │
│     │                                                           │
│     │ 输出：                                                    │
│     │ ├─ 所有 HTTP 路由列表                                     │
│     │ ├─ 每个路由的参数定义                                     │
│     │ │   ├─ 参数名、类型                                       │
│     │ │   └─ JSON 内部字段（如 pageJson.orderBy）               │
│     │ └─ Burp Suite 请求模板                                    │
│     │                                                           │
│     ↓                                                           │
│  [步骤2] java-sql-audit（本技能）                               │
│     │                                                           │
│     │ 输入：java-route-mapper 的输出                            │
│     │                                                           │
│     │ 执行：                                                    │
│     │ ├─ 快速扫描高危文件                                       │
│     │ ├─ 参数-SQL 映射分析                                      │
│     │ ├─ 检查每个 String 参数是否进入 SQL                       │
│     │ └─ 执行条件分析                                           │
│     │                                                           │
│     ├─── 需要深入追踪 ───→ java-route-tracer                    │
│     │                           │                               │
│     │    ←── 返回调用链信息 ────┘                               │
│     │                                                           │
│     ↓                                                           │
│  [步骤3] 输出综合审计报告                                       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

输入依赖（来自 java-route-mapper）

在开始审计前，应先检查是否已有 java-route-mapper 的输出文件：

{project_name}_audit/
├── route_mapper/
│   └── {route_name}/
│       └── {project_name}_routes_{timestamp}.md    ← 检查此文件
└── sql_audit/
    └── {route_name}/
        └── {project_name}_sql_audit_{timestamp}.md  ← 本技能输出

如果 route_mapper 输出不存在，建议先运行：

Skill(skill="java-route-mapper", args="--project {project_path}")

从 route_mapper 获取的关键信息

信息	用途
路由路径	定位 Controller/Action 入口
参数名 + 类型	识别 String 类型高危参数
JSON 内部字段	识别嵌套参数（如 `pageJson.orderBy`）
参数用途描述	判断是否用于 SQL（排序、分组等）

工作流程（三阶段）

阶段1: 快速扫描（优先执行）

目标：快速定位高危文件和模式，不遗漏关键点。

# 1.1 搜索分页/排序辅助类（最易遗漏）
find . -name "*Pagination*.java" -o -name "*PageHelper*.java" -o -name "*Pager*.java"
find . -name "*JdbcSupport*.java" -o -name "*JdbcTemplate*.java"

# 1.2 搜索 DAO 基类
find . -name "Abstract*Dao*.java" -o -name "Base*Dao*.java" -o -name "*Support.java"

# 1.3 搜索 ORDER BY 拼接模式
grep -ri "order by" --include="*.java" | grep -v "ORDER BY \?"
grep -ri "getOrderBy\|getSortField\|getOrder\|getSortOrder" --include="*.java"
grep -ri "append.*order" --include="*.java"

# 1.4 搜索 SQL 执行点
grep -ri "executeQuery\|executeUpdate\|prepareStatement" --include="*.java"
grep -ri "createQuery\|createNativeQuery\|createSQLQuery" --include="*.java"

输出：高危文件清单（按优先级排序）

优先级	文件类型	审计重点
P0	`Pagination.java`, `PageHelper.java`	orderBy, order, sort 参数
P1	`AbstractDao.java`, `BaseDao.java`	通用 SQL 构建方法
P2	`Mapper.java`, `Dao.java`, `*Repository.java`	业务 SQL 操作
P3	`*Mapper.xml`	MyBatis ${} 使用

阶段2: 参数-SQL 映射分析

基于 java-route-mapper 的输出，分析每个参数是否进入 SQL。

2.1 高危参数识别

从 route_mapper 输出中提取所有 String 类型参数：

参数来源	参数名	类型	SQL 风险
pageJson	`orderBy`	String	高危 - 排序字段
pageJson	`order`	String	高危 - 排序方向
searchJson	`keyword`	String	高危 - 搜索关键词
searchJson	`status`	String	中危 - 状态筛选
pageJson	`pageSize`	int	低 - 数值类型

2.2 参数追踪

对每个高危参数，追踪其在代码中的使用：

HTTP 参数: pageJson.orderBy (String)
    ↓ 反序列化
Page.orderBy
    ↓ 传递
Service.method(page)
    ↓ 传递
Dao.query(page)
    ↓ 调用
AbstractDao.findSql(page)
    ↓ 使用
sql.append(" order by ").append(page.getOrderBy())  ← SQL 拼接点

2.3 SQL 执行点检查

对阶段1发现的每个 SQL 执行点，检查：

是否使用参数化查询？
- PreparedStatement + ? 占位符 → 安全
- 字符串拼接 → 危险
拼接的参数来源？
- 来自 HTTP 请求的 String 参数 → 高危
- 来自系统配置/常量 → 安全
- 来自数据库查询结果 → 需进一步分析
是否有输入校验？
- 白名单校验 → 安全
- 无校验直接拼接 → 高危

阶段3: 深入分析与报告

3.1 触发 java-route-tracer

当发现以下情况时，调用 java-route-tracer 获取完整调用链：

触发条件	调用方式
参数经过多层传递	`Skill(skill="java-route-tracer", args="--route {route}")`
分支条件不明确	`Skill(skill="java-route-tracer", args="--route {route}")`
父类 SQL 执行	`Skill(skill="java-route-tracer", args="--route {route}")`

3.2 执行条件分析

发现 SQL 拼接后，必须分析执行条件（详见后续章节）。

3.3 生成报告

整合所有分析结果，生成综合审计报告。

SQL 框架识别

框架	识别特征	配置文件	参考资料
JDBC	`java.sql.*`, `Statement`, `PreparedStatement`, `DriverManager`	-	JDBC.md
MyBatis	`@Mapper`, `@Select`, `SqlSession`, `#{}`/`${}`	`mybatis-config.xml`, `*Mapper.xml`	MYBATIS.md
Hibernate	`@Entity`, `Session.createQuery()`, `HQL`, `Criteria`	`hibernate.cfg.xml`, `persistence.xml`	HIBERNATE.md

3. 反编译阶段（CRITICAL）

当源码不可用时，必须使用 MCP Java Decompiler 反编译 SQL 相关类。

详细策略参见 DECOMPILE_STRATEGY.md

3.1 反编译工具调用

# 反编译单个 DAO/Mapper 类
mcp__java-decompile-mcp__decompile_file(
    file_path="/path/to/UserMapper.class",
    output_dir="/path/to/decompiled",
    save_to_file=True
)

# 反编译 DAO 相关目录
mcp__java-decompile-mcp__decompile_directory(
    directory_path="/path/to/WEB-INF/classes/com/example/dao",
    output_dir="/path/to/decompiled",
    recursive=True,
    save_to_file=True,
    max_workers=4
)

# 反编译多个指定文件
mcp__java-decompile-mcp__decompile_files(
    file_paths=[
        "/path/to/UserDao.class",
        "/path/to/OrderService.class",
        "/path/to/BaseMapper.class"
    ],
    output_dir="/path/to/decompiled",
    save_to_file=True
)

3.2 必须反编译的类

类型	匹配模式	目的
DAO/Mapper	`Dao.class`, `Mapper.class`, `*Repository.class`	提取 SQL 执行逻辑
Service	`Service.class`, `ServiceImpl.class`	追踪 SQL 调用链
工具类	`SqlUtil.class`, `DbHelper.class`	提取通用 SQL 方法
实体类	`Entity.class`, `Model.class`	Hibernate 注解分析

执行条件分析（CRITICAL - 避免误报）

发现 SQL 拼接代码后，必须分析该代码是否真的会被执行！

1. 数据库类型分支检查

在发现 SQL 拼接后，必须检查是否存在数据库类型判断：

检查模式	代码特征	处理方式
Oracle 分支	`isOracle()`, `getDbType().equals("oracle")`	标注为 Oracle-only
MySQL 分支	`isMySQL()`, `isMySql()`, `getDbType().equals("mysql")`	标注为 MySQL-only
通用代码	无数据库类型判断	标注为通用

示例分析：

public String getSql(QueryBean bean, List<Object> params) {
    if (this.isOracle()) {
        return this.getOracleSql(bean, params);  // Oracle分支 - SQL拼接在这里
    }
    return "";  // ⚠️ MySQL分支 - 直接返回空字符串！
}

2. 代码路径可达性分析

追踪从入口到 SQL 执行的完整路径，检查：

检查项	说明	影响
提前 return	`return ""`, `return null`	代码不执行
异常抛出	`throw new Exception()`	代码不执行
条件不满足	`if (false)` 等死代码	代码不执行
环境限定	仅特定数据库/配置下执行	需确认环境

3. 结论分级（必须标注）

状态	含义	后续操作
⚠️ 待验证	代码存在 SQL 拼接，但执行条件未确认	需确认目标环境
✅ 已确认可利用	已验证代码路径在目标环境下会执行	进行漏洞利用测试
❌ 不可利用	代码存在但在目标环境下不执行	标注原因，降低优先级
🔍 环境依赖	漏洞存在但仅在特定环境下可利用	标注环境条件

4. 审计流程修正

发现 SQL 拼接代码
       ↓
检查是否有数据库类型分支（isOracle/isMySQL）
       ↓
  ┌────┴────┐
  有        无
  ↓         ↓
分析各分支   继续常规分析
  ↓
确认目标环境数据库类型
  ↓
判断漏洞代码是否会执行
  ↓
  ┌────┴────┐
 执行      不执行
  ↓         ↓
标注✅     标注❌
已确认     不可利用

5. 报告输出要求

发现 SQL 拼接时，必须在报告中包含：

### 执行条件分析

| 项目 | 值 |
|------|-----|
| 代码位置 | AnalyseDaoImpl.java:187 |
| 分支条件 | `if (this.isOracle())` |
| Oracle 分支 | 调用 getOracleSql() → SQL 拼接 |
| MySQL 分支 | `return ""` → 不执行 |
| 目标环境 | MySQL |
| **可利用性** | ❌ 不可利用（MySQL 环境下代码路径不执行） |

SQL 注入检测规则速查

核心检测原则

基于行为识别，而非固定命名模式。开发者可能使用任意命名，固定模式会导致漏报！

原则	说明
行为优先	搜索 SQL 关键字拼接行为，而非方法名/类名
数据流追踪	追踪任何 String 参数是否流入 SQL
多数据库覆盖	检测需覆盖 Oracle、MySQL、PostgreSQL、SQL Server 等

详细检测策略请参考：SQL_DETECTION_RULES.md

检测规则参考

检测类型	说明	参考文档
通用行为检测	SQL 关键字拼接、数据流追踪、分页排序	SQL_DETECTION_RULES.md
JDBC 框架	Statement、PreparedStatement、参数化	JDBC.md
MyBatis 框架	`#{}` vs `${}`、动态 SQL	MYBATIS.md
Hibernate 框架	HQL、Criteria、Native Query	HIBERNATE.md

快速检测命令

# 搜索 SQL 关键字拼接（通用，不依赖命名）
grep -ri "order by\|group by" --include="*.java" | grep -E "\+|\.append"
grep -ri "limit\s|offset\s|rownum|row_number" --include="*.java"

⚠️ 参数类型与注入风险

SQL 注入漏洞主要发生在 String 类型参数上！

参数类型	注入风险	原因
`String`	高危	可注入任意 SQL 片段
`Integer`/`int`	低	非法输入会抛 NumberFormatException
`Long`/`long`	低	非法输入会抛 NumberFormatException
`Boolean`/`boolean`	低	只能是 true/false

审计要点：

重点关注 String 类型参数的 SQL 拼接
特别关注 orderBy、order、groupBy 等排序/分组参数
数值类型参数即使拼接，也难以注入（但仍建议使用预编译）
检查是否有 String 转数值的中间处理

JDBC 危险 vs 安全 → 详细规则

类型	危险模式	安全模式
查询	`stmt.executeQuery("..."+var)`	`pstmt.setXxx(1, var)`
拼接	`+`, `StringBuilder`, `String.format`	`?` 占位符
ORDER BY	`" order by " + orderBy`	白名单校验

MyBatis 危险 vs 安全 → 详细规则

类型	危险模式	安全模式
参数	`${param}`	`#{param}`
like	`'%${keyword}%'`	`CONCAT('%', #{keyword}, '%')`
order by	`ORDER BY ${col}`	白名单校验后使用
in	`IN (${ids})`	`<foreach>` 标签

Hibernate 危险 vs 安全 → 详细规则

类型	危险模式	安全模式
HQL	`"FROM User WHERE name='"+n+"'"`	`query.setParameter("name", n)`
Native	`createNativeQuery(sql+var)`	参数绑定
Criteria	`Restrictions.sqlRestriction(str)`	`CriteriaBuilder` API
排序	`" order by " + sortField`	白名单校验

需要详细检测规则时，点击对应框架链接加载完整文档。

审计检查清单（防遗漏）

必须搜索的危险模式

在审计开始时，必须执行以下搜索：

# ORDER BY 注入检测
grep -r "order by" --include="*.java" | grep -v "ORDER BY \?"
grep -r "getOrderBy\|getSortField\|getOrder\|getSortOrder" --include="*.java"
grep -r "append.*order" --include="*.java"

# GROUP BY 注入检测
grep -r "group by" --include="*.java" | grep -v "GROUP BY \?"
grep -r "getGroupBy" --include="*.java"

# 分页辅助类检测
find . -name "*Pagination*.java" -o -name "*PageHelper*.java" -o -name "*JdbcSupport*.java"

# 基类检测
find . -name "Abstract*Dao*.java" -o -name "Base*Support*.java"

数据流追踪（需要时加载 java-route-tracer）

何时需要参数追踪

当发现以下情况时，建议加载 java-route-tracer 技能进行深度追踪：

场景	说明	操作
参数经过多层传递	HTTP 参数经 Controller → Service → DAO 多层传递后拼接 SQL	加载 java-route-tracer
参数类型转换	String JSON 反序列化为对象后，某字段用于 SQL	加载 java-route-tracer
父类/基类 SQL 执行	SQL 执行在父类 AbstractDao 等基类中	加载 java-route-tracer
变量名多次变化	同一参数在不同层使用不同变量名	加载 java-route-tracer

自动触发 java-route-tracer（Claude Code 规范）

当发现以下场景时，必须自动调用 java-route-tracer 技能：

# 当需要追踪参数流向时，自动调用 java-route-tracer
mcp__cclsp__find_references  # 先分析方法引用
# 然后自动触发
Skill(
    skill="java-route-tracer",
    args="--route {controller_route} --project {project_path}"
)

基于 tracer 输出的漏洞判定（CRITICAL - 防止误判）

java-sql-audit 必须基于 java-route-tracer 的"参数实际使用分析"输出进行漏洞判定。

判定流程

1. 调用 java-route-tracer 获取追踪报告
       ↓
2. 读取"参数实际使用分析"章节
       ↓
3. 筛选参数
   ├─ "✅ 被使用" → 进行 SQL 注入检测
   ├─ "❌ 未使用" → 跳过，不标记为漏洞
   └─ "⚠️ 部分使用" → 仅检测被使用的字段
       ↓
4. 对"被使用"的参数进行详细分析
       ↓
5. 输出审计结论

tracer 输出示例与 audit 判定

参数	tracer 输出（实际使用状态）	sql-audit 判定
page.orderBy	❌ 未使用（被硬编码覆盖）	⏭️ 跳过，不检测
page.order	❌ 未使用（被硬编码覆盖）	⏭️ 跳过，不检测
searchBean.keyword	✅ 被使用（`#{keyword}` 参数化）	🔍 检测 → 安全（参数化）
searchBean.status	✅ 被使用（`${status}` 拼接）	🔍 检测 → 发现漏洞

审计报告中的体现

### [SQL-001] ORDER BY 注入分析

| 检查项 | 结果 |
|:-------|:-----|
| 拼接代码位置 | PaginationJdbcSupport.java:115 |
| 调用方法 | UserBulletinDaoImpl.getUserBulletinReplayList() |
| **tracer 参数分析** | page.orderBy → ❌ 未使用（被硬编码覆盖） |
| 硬编码详情 | `sql + " order by replayDateStr desc"` |
| **结论** | ❌ **非漏洞** - 参数未实际使用 |

---

### [SQL-002] WHERE 条件 SQL 注入

| 检查项 | 结果 |
|:-------|:-----|
| 拼接代码位置 | UserDaoImpl.java:89 |
| 调用方法 | UserDaoImpl.searchUsers() |
| **tracer 参数分析** | searchBean.status → ✅ 被使用（`${status}` 拼接） |
| 参数来源 | HTTP 请求 searchJson.status |
| **结论** | ✅ **确认漏洞** - 参数直接拼接到 SQL |

必须检查的 tracer 输出字段

tracer 输出字段	用途
`实际使用状态`	判断是否需要检测该参数
`是否被硬编码覆盖`	排除硬编码场景的误判
`敏感操作类型`	确定检测规则（SQL/命令/SSRF等）
`硬编码覆盖详情`	输出到审计报告作为证据

触发条件（自动调用）

场景	操作
参数经过多层传递	调用 java-route-tracer 追踪完整调用链
参数类型转换	调用 java-route-tracer 追踪参数转换过程
父类/基类 SQL 执行	调用 java-route-tracer 追踪继承链
变量名多次变化	调用 java-route-tracer 追踪变量名变化
执行条件不明确	调用 java-route-tracer 分析分支条件

java-route-tracer 协作内容

调用时传递的参数：

--route: 对应的 HTTP 路由（如 /api/users/getUserById）
--project: 项目路径（用于反编译和代码分析）

java-route-tracer 返回：

完整调用链信息（L1 → L2 → L3 → L4）
各层的参数变量名变化
执行路径的分支条件分析
最终 SQL 使用点定位
HTTP 请求模板（Burp Suite 可用）

协作流程：

java-sql-audit                    java-route-tracer
     │                                   │
     │  发现 SQL 注入点                   │
     │  检测到需要深度追踪的场景          │
     │                                   │
     └───────── Skill 工具调用 ──────────→│
                                         │
                                         │  追踪完整调用链
                                         │  分析分支条件
                                         │  输出参数流向
                                         │
     ←───────── 自动返回结果 ─────────────┘
     │
     │  结合追踪结果标注可利用性
     ▼

报告生成

输出单个综合审计报告文件：

{project_name}_audit/sql_audit/
└── {route_name}/
    └── {project_name}_sql_audit_{timestamp}.md      # 综合审计报告

路由名说明：

路由名从路由路径提取，去掉前缀斜杠和特殊字符
例如：/itc/ws/carQuery → itc_ws_carQuery
例如：/api/user/login.action → api_user_login

输出格式

综合报告模板（{project_name}sql_audit{timestamp}.md）

# {项目名称} - SQL 注入审计报告

生成时间: {timestamp}
分析路径: {project_path}

---

## 1. 审计概述

| 项目 | 信息 |
|------|------|
| 审计范围 | {project_path} |
| SQL 框架 | {JDBC/MyBatis/Hibernate} |
| 分析方法 | 静态代码审计 + 数据流分析 |

---

## 2. 风险统计

| 严重等级 | CVSS | 数量 | 说明 |
|----------|------|------|------|
| 🔴 C (Critical) | 9.0-10.0 | {count} | 可直接导致系统沦陷 |
| 🟠 H (High) | 7.0-8.9 | {count} | 可造成重大损害 |
| 🟡 M (Medium) | 4.0-6.9 | {count} | 可造成一定损害 |
| 🔵 L (Low) | 0.1-3.9 | {count} | 安全加固建议 |

---

## 3. SQL 操作映射表

| 序号 | 类名 | 方法 | 框架 | SQL类型 | 参数化状态 | 可利用性 |
|------|------|------|------|---------|------------|----------|
| 1 | UserMapper | findById | MyBatis | SELECT | ✅ 安全 | - |
| 2 | UserMapper | findByName | MyBatis | SELECT | ❌ 危险 | ⚠️ 待验证 |

---

## 4. 高危风险详情

### [{C/H/M/L}-SQL-{序号}] {风险标题}

| 项目 | 信息 |
|------|------|
| 严重等级 | {🔴/🟠/🟡/🔵} {Critical/High/Medium/Low} (CVSS {score}) |
| 可达性 (R) | {0-3} - {判定理由} |
| 影响范围 (I) | {0-3} - {判定理由} |
| 利用复杂度 (C) | {0-3} - {判定理由} |
| 可利用性 | ✅ 已确认 / ⚠️ 待验证 / ❌ 不可利用 / 🔍 环境依赖 |
| 位置 | {ClassName.method} ({file}:{line}) |
| 框架 | {JDBC/MyBatis/Hibernate} |

#### 执行条件分析

| 项目 | 值 |
|------|-----|
| 分支条件 | `if (this.isOracle())` |
| Oracle 分支 | 调用 getOracleSql() → SQL 拼接 |
| MySQL 分支 | `return ""` → 不执行 |
| 目标环境 | {MySQL/Oracle/未知} |
| **结论** | {已确认可利用/不可利用/需确认环境} |

#### 漏洞代码

\```java
// 危险代码片段
String sql = "SELECT * FROM users WHERE id = " + id;
\```

#### 数据流分析

\```
用户输入: {Controller 入口}
     ↓
参数传递: {Service 调用}
     ↓
SQL 执行: {DAO/Mapper 方法}
     ↓
  ┌────┴────┐
[if Oracle]  [else]
     ↓         ↓
SQL拼接    return ""
\```

#### 验证 PoC

\```http
GET /api/users?id=1' OR '1'='1 HTTP/1.1
Host: {{host}}
\```

#### 建议修复

\```java
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, id);
\```

---

## 5. 验证 Payload 参考

| 注入类型 | 测试 Payload | 预期结果 |
|----------|--------------|----------|
| 基于错误 | `'` | 数据库错误信息 |
| 布尔盲注 | `1' AND '1'='1` | 正常响应 |
| 时间盲注 | `1' AND SLEEP(5)--` | 延迟响应 |
| UNION 注入 | `1' UNION SELECT 1,2,3--` | 额外数据 |

---

## 6. 审计结论

| 统计项 | 数量 |
|--------|------|
| 总 SQL 操作数 | {count} |
| 安全操作 | {count} |
| 危险操作 | {count} |
| 可利用漏洞 | {count} |
| 环境依赖漏洞 | {count} |

验证检查清单

在标记审计完成前，必须执行以下检查：

代码分析检查

所有 DAO/Mapper 类已分析
所有 SQL 配置文件（*Mapper.xml）已解析
每个 SQL 操作都有参数化状态标注

执行条件检查（CRITICAL）

检查了数据库类型分支（isOracle/isMySQL）
分析了代码路径可达性
标注了每个漏洞的可利用性状态

漏洞检测检查

所有 JDBC 拼接模式已检测
所有 MyBatis ${} 使用已检测
所有 Hibernate HQL 拼接已检测

报告完整性检查

综合审计报告已生成

参考资料

JDBC.md - JDBC SQL 注入审计详解
MYBATIS.md - MyBatis SQL 注入审计详解
HIBERNATE.md - Hibernate SQL 注入审计详解
DECOMPILE_STRATEGY.md - 反编译策略指南