夜雨聆风前言
通用大语言模型在代码生成、语义理解、多轮推理等任务上展现的能力，让人不禁思考一个问题：把这些能力映射到渗透测试的场景中，边界在哪里？
渗透测试的很多环节确实依赖"理解"和"推理"：理解一个 HTTP 接口是干什么的、推断一个参数的业务语义、对比两次响应的差异并判断它是不是漏洞证据。从能力对位的角度，LLM 似乎天然适合这些任务。
与此同时，AI coding 正在显著缩短编码周期——代码写得更快了，留给安全测试的时间窗口势必收窄。测试效率的提升不再是"锦上添花"，而是一个务实的需求。
但当我们真正把 LLM 接入 Burp Suite 的数据流，让它直面真实的 HTTP 请求和响应时，很快就碰到了几个技术层面的根本矛盾：
- 确定性与非确定性的冲突：渗透测试要求结果可复现——同一个 payload、同一个参数、重复验证应该得到相同结论。但 LLM 的输出天然非确定。
- 语义理解与精确判定的错位：LLM 在宏观的接口语义理解上表现惊艳，但在精确判定"这个差异的 3 个字节变化是否构成漏洞证据"时表现不稳定。
- 成本结构与高频场景的冲突：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 分层设计的原则
整个架构围绕三条原则展开：
- HTTP-first：重放、差异计算、请求构造是通用能力，不绑定到特定漏洞类型。SQL 注入和 XSS 共用同一套发请求和比对响应的基础设施。
- 规则优先于硬编码：检测逻辑优先写在 YAML 中，Java 只负责执行框架。新增漏洞类型不需要修改 Java 代码。
- 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_recoverytechnique: ERROR_BASEDstrategy: ERROR_BASEDstrength: WEAKpriority: 1stopOnMatch: falsemaxRequests: 2maxPayloadLength: 16evidenceWeight: 0.88applicableParamTypes: [QUERY, BODY, PATH]valueTypes: [STRING, EMAIL, URL, UNKNOWN, NUMERIC]payloads:- value: "'"role: TRIGGERmutation: APPEND- value: "''"role: RECOVERYmutation: APPENDoracle:type: ERROR_KEYWORD_OR_RECOVERYerrorKeywords:- "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
