乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > AI 辅助渗透测试和漏洞挖掘的思考和尝试

AI 辅助渗透测试和漏洞挖掘的思考和尝试

当前时间： 2026-08-15 11:45:46 分类：办公文件 评论(0)
AI 辅助渗透测试和漏洞挖掘的思考和尝试

前言

通用大语言模型在代码生成、语义理解、多轮推理等任务上展现的能力，让人不禁思考一个问题：把这些能力映射到渗透测试的场景中，边界在哪里？

渗透测试的很多环节确实依赖"理解"和"推理"：理解一个 HTTP 接口是干什么的、推断一个参数的业务语义、对比两次响应的差异并判断它是不是漏洞证据。从能力对位的角度，LLM 似乎天然适合这些任务。

与此同时，AI coding 正在显著缩短编码周期——代码写得更快了，留给安全测试的时间窗口势必收窄。测试效率的提升不再是"锦上添花"，而是一个务实的需求。

但当我们真正把 LLM 接入 Burp Suite 的数据流，让它直面真实的 HTTP 请求和响应时，很快就碰到了几个技术层面的根本矛盾：

  1. 确定性与非确定性的冲突：渗透测试要求结果可复现——同一个 payload、同一个参数、重复验证应该得到相同结论。但 LLM 的输出天然非确定。
  1. 语义理解与精确判定的错位：LLM 在宏观的接口语义理解上表现惊艳，但在精确判定"这个差异的 3 个字节变化是否构成漏洞证据"时表现不稳定。
  1. 成本结构与高频场景的冲突：LLM 每次调用有延迟和 token 开销，而参数级验证往往涉及数百次请求，成本模型不匹配。

基于这些认识，我们针对 AI pentest 做了一些尝试，输出了一款用于辅助 Burp 渗透测试的插件 AI-Burp-Copilot：https://github.com/zxcvbn001/AI-Burp-Copilot

一、AI Burp Copilot 的设计

1.1 任务拆解：渗透测试中的"理解"与"执行"

在着手实现之前，我们先对渗透测试的工作流做了任务拆解。一个典型的验证链路可以抽象为三个层次：

理解层：这个接口是干什么的？参数有什么业务含义？可能存在哪类风险？
  ↓
执行层：对哪个参数、用什么 payload、怎么判断响应？
  ↓
复核层：这个响应差异是漏洞证据还是业务正常行为？

三层任务的本质不同：

层次

任务性质

适合的执行体

理解层

语义分析、模糊分类、开放推理

LLM（擅长上下文理解）

执行层

精确构造、批量重放、规则匹配

规则引擎（擅长确定执行）

复核层

差异解读、合理解释、误报过滤

LLM + 规则引擎协同

这个拆解决定了项目的核心架构决策：不是让 LLM 从头到尾主导整个流程，而是把 LLM 嵌入到工作流的两个特定入口——前端做分析，后端做复核。中间的精确执行全部交给规则引擎。

1.2 为什么不直接用 LLM 驱动执行

从测试情况来看，用 LLM 直接控制请求构造和发送存在三个层面的问题，且不是"换更强的模型"能解决的：

问题一：确定性缺失。渗透测试要求 payload 和响应之间的因果关系是确定的——发了 payload A，得到响应 B，结论是 C。换个测试人员重复做，应该得到相同的 C。但 LLM 的输出天然有概率性，temperature=0 在简单任务上可以缓解，在需要判断"响应差异是否有语义含义"这种模糊任务上，重复性无法保证。而安全测试的结论必须是可复现的，否则无法作为正式交付物。

问题二：执行效率不匹配。参数级验证往往涉及大量请求——一个接口 10 个参数，每个参数 3-5 条 payload，每条 payload 需要发 baseline 和变异两次请求，再计算差异。这还没有考虑布尔盲注中可能需要多次请求来确认真伪条件。用 LLM 逐个判断每条响应的开销（每次调用数百毫秒到数秒 + token 费用）在这个量级下不可接受。规则引擎做一次响应比对是微秒级，差异是三个数量级。

问题三：审计链路断裂。LLM 直接发包意味着"为什么发这个请求"的决策过程在模型内部，不可审计。如果 LLM 构造了一个删除操作的请求，审计时无法回答"是谁决定发这个请求的、依据是什么"。规则引擎的每个 payload、每个 oracle 判定逻辑都是显式定义在 YAML 文件中的，可审查、可追溯。

1.3 架构总览

基于上述分析，AI Burp Copilot 的整体架构如下：

Burp HTTP Traffic  │  ▼┌──────────────────────────────────────────────────┐│              Pipeline 编排层                       ││  (线程池驱动，2 workers，1000 队列容量)             │├──────────────────────────────────────────────────┤│  Stage 1: 流量采集与历史存储                       ││  Stage 2: 去重（URI 模板级）                      ││  Stage 3: 状态码过滤（跳过 204/304 等无效响应）     ││  Stage 4: 端点分类 [LLM] — 业务接口还是静态资源？   ││  Stage 5: 静态扫描 — 正则规则检测敏感信息泄露       ││  Stage 6: AI 分析 [LLM] — 攻击面识别、参数提取      ││  Stage 7: 风险评估 — 候选漏洞排序与优先级           ││  Stage 8: 工作流验证 — 规则引擎执行                 │└──────────────────────────────────────────────────┘  │  ▼┌──────────────────────────────────────────────────┐│              验证引擎（Stage 8 内部）               │├──────────────────────────────────────────────────┤│  ① 参数影响力评估                                 ││     — 最小化变异 + baseline 重放 + diff 计算       ││     — 确认参数是否真正影响服务端行为               ││  ② 规则匹配                                      ││     — 从 YAML 规则库加载匹配的 probe 定义           ││     — 按 attackType 和策略筛选适用的 oracle        ││  ③ Probe 执行                                    ││     — 构造变异请求 → 发送 → diff 计算              ││     — 本地 oracle 判定（9 种判定方式）              ││  ④ LLM 二次复核 [LLM]                            ││     — 对弱差异场景做语义复核                       ││  ⑤ Finding 聚合                                  ││     — 置信度合并（1 - ∏(1-ci)）                   ││     — 阈值过滤（默认 0.55）                        │└──────────────────────────────────────────────────┘  │   ▼┌──────────────────────────────────────────────────┐│  UI 展示层                                        ││  History / Endpoint Analysis / Parameter          ││  Verification / Static Scan / Findings / Report   │└──────────────────────────────────────────────────┘

项目在代码组织上分为以下几个核心模块：

  • pipeline/ — 流水线编排，每个阶段实现 IPipelineStage 接口，支持独立开关和热加载 
  • verification/ — 验证引擎核心，包含 influence（参数影响力）、payload（规则加载）、probe（探测执行）、oracle（证据判定）、finding（结果聚合）、review（LLM 复核） 
  • ai/ — AI 提供者抽象层，支持 OpenAI / DeepSeek / Qwen / OpenAI 兼容协议，通过 Factory 模式运行时切换 
  • config/ — 外置配置加载，application.yml 管理 LLM 端点、密钥、速率限制 
  • prompts/ — 提示词模板文件，分 endpoint-analysis-v1 / diff-judge-v1 / endpoint-classifier-v1 三个独立 prompt，各自聚焦不同的分析任务 

1.4 分层设计的原则

整个架构围绕三条原则展开：

  1. HTTP-first：重放、差异计算、请求构造是通用能力，不绑定到特定漏洞类型。SQL 注入和 XSS 共用同一套发请求和比对响应的基础设施。 
  1. 规则优先于硬编码：检测逻辑优先写在 YAML 中，Java 只负责执行框架。新增漏洞类型不需要修改 Java 代码。 
  1. LLM 在边界上：LLM 只出现在工作流的入口（分类、分析）和出口（复核），不进入执行链路内部。这样可以随时替换 AI 提供者而不影响核心验证逻辑。 

二、关键实现细节

这部分只简短介绍，详细可以查看项目使用手册https://github.com/zxcvbn001/AI-Burp-Copilot/blob/main/docs/user-guide.md

2.1 YAML 规则定义

规则引擎的核心是 YAML 定义文件。Java 代码只提供"发请求、收响应、计算差异"的执行框架，具体"测什么、怎么测、怎么判"写在规则文件中。一个典型的 SQL 注入规则片段：

probes:  - id: generic_quote_error_recovery    technique: ERROR_BASED    strategy: ERROR_BASED    strength: WEAK    priority: 1    stopOnMatch: false    maxRequests: 2    maxPayloadLength: 16    evidenceWeight: 0.88    applicableParamTypes: [QUERY, BODY, PATH]    valueTypes: [STRING, EMAIL, URL, UNKNOWN, NUMERIC]    payloads:      - value: "'"        role: TRIGGER        mutation: APPEND      - value: "''"        role: RECOVERY        mutation: APPEND    oracle:      type: ERROR_KEYWORD_OR_RECOVERY      errorKeywords:        - "sql syntax"        - "database error"        - "mysql"        - "postgresql"        - "sqlite"        - "oracle"        - "sql server"        - "sqlstate"        - "odbc"        - "jdbc"        - "unclosed quotation mark"                - "quoted string not properly terminated"      minConfidence: 0.78

新增漏洞类型只需要编写新的 YAML 文件，放入 rules/payloads/ 目录，插件热加载即可识别。当前规则库覆盖 15+ 漏洞类型，包括 SQLi、XSS、IDOR、SSRF、命令注入、JWT、SSTI、XXE、CORS 等。

2.2 Oracle 证据判定

规则引擎发完 payload 后，通过预定义的 Oracle 类型判断是否存在漏洞证据。当前支持 9 种判定方式：

Oracle 类型

判定逻辑

典型用途

ERROR_KEYWORD_OR_RECOVERY

响应中出现错误关键字，或 baseline 有错误而 probe 恢复

SQL 注入报错检测

TIME_DELAY

响应时间超过阈值且 baseline 正常

时间盲注

HTML_REFLECTION

payload 出现在响应 HTML 中

XSS 反射检测

PAIR_DIFF

两条 probe 响应之间的差异超过阈值

布尔盲注

REDIRECT_LOCATION

响应状态码为 3xx 且 Location 可控

开放重定向

BASELINE_DIFF

probe 响应与 baseline 差异超过阈值

通用检测

BASELINE_SIMILAR

probe 响应与 baseline 相似度超过阈值

确认无影响

EXPRESSION_EVALUATION

模板表达式被执行

SSTI

KEYWORD

响应匹配预定义关键字

通用匹配

每种 Oracle 输出一个置信度分数（0~1）。当多个 probe 命中同一 Finding 时，置信度通过 confidence = 1 - ∏(1 - ci) 合并。默认阈值 0.55，用户可在设置中调整。

2.3 参数影响力评估

在进入规则验证之前，增加了一个预筛阶段：对候选参数做最小化变异（如数字参数 +1），重新发送请求，计算与 baseline 的差异。只有确认参数确实影响服务端行为，才进入后续验证。这一步过滤掉了大量无关参数，避免无效探测请求。

2.4 证据链设计

每次 probe 执行保留完整的上下文：

  • baseline 请求/响应
  • 变异请求/响应
  • 响应差异摘要
  • 本地 oracle 判定结果及置信度
  • LLM 复核意见（如启用）
  • 最终聚合置信度

所有链路上数据均通过 WorkflowContext 透传，确保每个 Finding 可逐条回溯到原始 Burp 流量。

三、一些真实的困境

3.1 LLM 的不一致性

这是 LLM 在这个场景下的天生缺陷。同一个接口、同一套参数，让 LLM 分析两次，可能给出不同的攻击面推荐。渗透测试需要结果可复现——上午验证了一个参数没问题，下午再跑一遍报了个高危——这在安全场景中是不可接受的。

我们目前的缓解手段：

  • 缓存 AI 分析结果，相同输入不走第二次
  • 固定 temperature 和 prompt 模板
  • 输出结构强校验（JSON schema binding）
  • 多模型评估：如果 GPT 和 DeepSeek 给出不同结论，降低置信度

但老实说，这个矛盾只能管理，无法消除。最终结论仍然需要规则引擎的本地判定来兜底。

3.2 业务逻辑漏洞的覆盖难题

SQL 注入、XSS 这类"模式固定"的漏洞，YAML 规则可以覆盖得很好。但业务逻辑漏洞——改个金额、跳个流程步骤、并发抢优惠券——高度依赖对业务流程的理解，规则引擎几乎无能为力。

我们目前的思路是：不试图用规则覆盖业务逻辑漏洞，而是用 LLM 做"风险提示"。后续LLM 分析接口时，如果发现参数包含金额、数量、状态等业务敏感字段，会标注"可能存在业务逻辑风险"，由人工决定是否深入验证。

这是一种"妥协方案"——让 AI 告诉你这里可能有坑，但要不要挖、怎么挖，还是人来定。

五、结语

AI Burp Copilot 不是一个"颠覆性"的项目，只是一次尝试，现阶段只能做个辅助工具。

项目已开源在 GitHub（https://github.com/zxcvbn001/AI-Burp-Copilot），如果你也在做类似的尝试，欢迎一起交流。

文章内容转自先知社区，原作者：zxcvbn001，侵删

原文链接：https://xz.aliyun.com/news/92147

END