AI助力Java代码审计 | SQL注入篇
字数 1633 2025-08-29 08:30:12

AI助力Java代码审计：SQL注入篇 - 详细教学文档

1. 环境准备

1.1 代码获取

  • 项目地址：https://github.com/crmeb/crmeb_java
  • 技术栈：Spring + Mybatis Plus 微服务框架
  • 架构：前后端分离

1.2 AI-IDE工具准备

  • 推荐使用Trae IDE（集成多个AI大模型）
  • 可用AI模型：
    • Claude 3.7（当前排队严重）
    • deepseek R1
    • 其他响应快速的模型

1.3 应用部署步骤

1.3.1 依赖下载

  • 通过pom.xml文件完成依赖下载

1.3.2 运行环境要求

  • Java
  • Redis
  • MySQL（可使用phpstudy集成环境）
  • Trae IDE集成环境

1.3.3 Redis配置

  • 默认无密码启动
  • 需修改：
    • 项目配置文件中redis密码设为空，或
    • 修改Redis数据库密码与项目配置一致

1.3.4 MySQL配置

  • 导入项目数据库
  • 修改数据库密码与项目配置一致

1.3.5 程序运行

  1. 运行Admin管理端
  2. 访问http://xxx/doc.html验证部署
  3. Web前端运行： 
    npm install  # 安装项目依赖
npm run dev  # 启动开发环境
  • 故障排除：将报错内容输入Trae进行诊断

参考文档：https://doc.crmeb.com/java/crmeb_java/2211

2. SQL注入审计方法

2.1 审计关键点

2.1.1 危险关键字搜索

  • ${}
  • createStatement
  • executeQuery
  • executeUpdate
  • StringBuilder.append
  • in/order by/like语句（无法预编译，常伴随动态拼接风险）
  • FIND_IN_SET
  • queryForObject
  • QueryWrapper
  • LambdaQueryWrapper

2.1.2 特定危险方法

  1. .apply方法：

    • 允许直接拼接SQL片段
    • 若未正确使用参数占位符({0}或?)且参数来自用户输入，可能引发注入

  2. .last()方法：

    • 直接追加SQL语句末尾
    • 若拼接用户输入(如limit值、排序字段等)，可能破坏SQL结构

2.2 AI辅助审计注意事项

  1. 等待WorkSpace索引建立完成
  2. AI分析存在：
    • 一定误报率
    • 可能产生幻觉（无中生有）
    • 上下文长度和token限制可能导致分析不全
  3. 建议：AI辅助审计，人工验证关键点

3. 实际漏洞案例分析

3.1 SQL注入点1

发现过程

  1. 全局搜索${发现2个mapper.xml文件
  2. StoreOrderMapper.xml中有三个SQL映射直接使用${}拼接

漏洞分析

  1. 第一次拼接：

    • 使用dateutil函数做格式化处理 → 安全

  2. 第二次拼接：

    if (!StringUtils.isBlank(request.getKeywords())) {
    where += " and (real_name like '%"+ request.getKeywords() +"%' or user_phone = '"+ request.getKeywords() +"' or order_id = '" + request.getKeywords() + "' or id = '" + request.getKeywords()
    • 直接拼接用户输入(request.getKeywords())
    • 无任何过滤或转义处理 → 存在SQL注入风险

  3. 第三次拼接：

    • 使用Integer强制数字型 → 安全

攻击路径

  • 通过Controller层参数传入恶意输入

3.2 SQL注入点2

发现过程

  • 使用关键字QueryWrapper搜索
  • 发现StoreProductServiceimp中存在SQL拼接

攻击示例

api/admin/store/product/list?page=1&limit=20&cateId=1'&keywords=&type=2&temp=1741250313

3.3 已修复的潜在风险点

  • tagidsql通过crmebutil的getfindsetsql方法做了处理
  • 对idStr做了字符串处理 → 不存在注入

4. 审计总结与最佳实践

4.1 审计流程建议

  1. 优先搜索高危关键字
  2. 逐层跟踪参数传递路径
  3. 验证用户输入是否经过适当处理
  4. 使用AI辅助但需人工验证

4.2 防御建议

  1. 避免直接拼接SQL语句
  2. 使用预编译和参数化查询
  3. 对必须的动态SQL进行严格过滤和转义
  4. 对数字型参数进行强制类型转换
  5. 使用框架提供的安全方法替代原生SQL

4.3 工具使用技巧

  1. 利用AI快速定位潜在风险点
  2. 结合传统静态分析工具
  3. 建立完整的审计跟踪路径
  4. 注意框架特定风险点（如Mybatis Plus的.apply和.last方法）
AI助力Java代码审计：SQL注入篇 - 详细教学文档 1. 环境准备 1.1 代码获取 项目地址：https://github.com/crmeb/crmeb_ java 技术栈：Spring + Mybatis Plus 微服务框架 架构：前后端分离 1.2 AI-IDE工具准备 推荐使用Trae IDE（集成多个AI大模型） 可用AI模型： Claude 3.7（当前排队严重） deepseek R1 其他响应快速的模型 1.3 应用部署步骤 1.3.1 依赖下载 通过pom.xml文件完成依赖下载 1.3.2 运行环境要求 Java Redis MySQL（可使用phpstudy集成环境） Trae IDE集成环境 1.3.3 Redis配置 默认无密码启动 需修改： 项目配置文件中redis密码设为空，或 修改Redis数据库密码与项目配置一致 1.3.4 MySQL配置 导入项目数据库 修改数据库密码与项目配置一致 1.3.5 程序运行 运行Admin管理端 访问http://xxx/doc.html验证部署 Web前端运行： 故障排除：将报错内容输入Trae进行诊断 参考文档：https://doc.crmeb.com/java/crmeb_ java/2211 2. SQL注入审计方法 2.1 审计关键点 2.1.1 危险关键字搜索 ${} createStatement executeQuery executeUpdate StringBuilder.append in/order by/like 语句（无法预编译，常伴随动态拼接风险） FIND_IN_SET queryForObject QueryWrapper LambdaQueryWrapper 2.1.2 特定危险方法 .apply 方法： 允许直接拼接SQL片段 若未正确使用参数占位符( {0} 或 ? )且参数来自用户输入，可能引发注入 .last() 方法： 直接追加SQL语句末尾 若拼接用户输入(如 limit 值、排序字段等)，可能破坏SQL结构 2.2 AI辅助审计注意事项 等待WorkSpace索引建立完成 AI分析存在： 一定误报率 可能产生幻觉（无中生有） 上下文长度和token限制可能导致分析不全 建议：AI辅助审计，人工验证关键点 3. 实际漏洞案例分析 3.1 SQL注入点1 发现过程 全局搜索 ${ 发现2个mapper.xml文件 StoreOrderMapper.xml中有三个SQL映射直接使用 ${} 拼接 漏洞分析 第一次拼接 ： 使用dateutil函数做格式化处理 → 安全 第二次拼接 ： 直接拼接用户输入(request.getKeywords()) 无任何过滤或转义处理 → 存在SQL注入风险 第三次拼接 ： 使用Integer强制数字型 → 安全 攻击路径 通过Controller层参数传入恶意输入 3.2 SQL注入点2 发现过程 使用关键字 QueryWrapper 搜索 发现StoreProductServiceimp中存在SQL拼接 攻击示例 3.3 已修复的潜在风险点 tagidsql通过crmebutil的getfindsetsql方法做了处理 对idStr做了字符串处理 → 不存在注入 4. 审计总结与最佳实践 4.1 审计流程建议 优先搜索高危关键字 逐层跟踪参数传递路径 验证用户输入是否经过适当处理 使用AI辅助但需人工验证 4.2 防御建议 避免直接拼接SQL语句 使用预编译和参数化查询 对必须的动态SQL进行严格过滤和转义 对数字型参数进行强制类型转换 使用框架提供的安全方法替代原生SQL 4.3 工具使用技巧 利用AI快速定位潜在风险点 结合传统静态分析工具 建立完整的审计跟踪路径 注意框架特定风险点（如Mybatis Plus的.apply和.last方法）