Blog

深浅模式

研究意义 ​

国内外研究现状及发展趋势 ​

研究内容 ​

研究进度安排 ​

任务执行 ​

任务执行面临两个挑战：讨论过程

  • 如何做出决策
  • Agent的抽象级别

web安全中的先前工作已经提出了强化学习 (RL) 方法来创建这样的代理，他们可以根据当前和过去的状态确定下一个动作。主要分为两种：一种是通过试错学习策略和适当的奖励函数来推导状态-动作映射。另外一种是利用用户提供的操作示例（预先录制的用户序列）来指导智能体（Agent）学习在 Web 界面上执行任务的方法。

从语义级别上表示动作、状态和目标，我们可以使用语言模型来预测下一个动作，作为下一个最可能的令牌序列。

如何定义的：

漏洞注入 ​

如何验证有WAF（待改进-还可以进一步细化）：

  • isWafIntercepted 方法通过检查相应内容中的关键词(如waf、拦截、安全狗)来判断请求是否被WAF拦截
  • 通过检查HTTP响应状态码（403,400，406）来快速判断是否被阻断

如何判断注入成功：

  • 首先会对相应进行初步的判断，如果响应码为200则考虑为没有被WAF拦截或绕过WAF成功，然后根据相应内容进行初步判断，也就是pyaload回显没有被转义或者删除。
  • 进一步会进行简单的外部回调验证，向监听器发送一个发起请求的payload，如果监听器收到了来自目标应用的HTTP请求，则证明执行。

PPT ​

概念语义表示实际代码表示 (示例)实现模块
状态 (State)当前页面的可交互元素摘要<button id=0>Login</button>\n<form id=1 ...>sensors.js
目标 (Goal)需要完成的任务描述"Log in to the application..."tasks-module.js
动作 (Action)对页面元素执行的操作指令CLICK 0 或 TYPE 1 "..."actuators.js (执行), llm-bridge.js (生成)

负责决定下一步应执行的操作。它将当前的任务目标、感知器生成的页面摘要以及存储在记忆库（Memory）中的历史操作记录，整合进Prompt中，并提交给LLM。LLM基于对任务的理解和当前页面的状态，推理出最合理的下一步动作，并输出一个标准化的动作指令（Action Abstraction）

任务的终止依赖两种机制：

  • LLM主动声明完成：在每次向 LLM 请求下一个动作时，提供给它的提示（Prompt）中不仅包含了当前页面的状态（abstractPage），还包含了需要完成的最终目标（任务描述）。
  • 示例:
    • 任务: "Log in to the application..."
    • 过程: LLM 指导浏览器填写用户名、密码，然后点击登录按钮。
    • 页面跳转: 浏览器跳转到了一个新的页面，比如 "Dashboard"。
    • 下一次循环: sensors.js 更新 abstractPage，新的页面内容可能是 <a id=0>Logout</a> 和 <p>Welcome, user!</p>。
    • LLM 推理: 程序将新的 abstractPage 和原始任务 "Log in..." 一起发给 LLM。LLM 看到 "Logout" 和 "Welcome" 等字样，推理出登录已经成功，任务已经完成。
    • LLM 输出: FINISHED
  • 声明了一个最大步骤数：maxStepsPerTask:15。有时候 LLM 可能会“卡住”，比如陷入循环（反复点击同一个链接）或者无法根据当前页面状态做出有效决策。为了防止程序因此无限执行下去，系统内置了一个简单的保护机制。
3.2.2 大模型提示词（Prompt）设计 ​

Payload生成的成功与否高度依赖于Prompt的设计。我们的Payload Prompt包含以下关键信息：

  1. 角色定义：指示LLM扮演一个精通XSS漏洞原理和WAF绕过技术的顶级网络安全专家。
  2. 上下文信息：提供注入点的详细上下文，包括页面URL、相关HTML片段（page/action abs）以及注入点在代码中的具体位置。
  3. 任务指令：明确要求LLM生成一个能够触发特定行为（如alert(1)）的XSS Payload。
  4. 对抗性要求与历史反馈：明确指示Payload需具备混淆性和非常规性，以绕过WAF。更重要的是，将WAF的历史拦截日志（log）作为反馈输入给LLM，告知其“你之前的尝试因何失败”，从而引导它在下一次生成中规避已有规则，形成迭代学习。
3.2.3 Payload生成与WAF绕过 ​

该方法的工作流程是一个闭环的对抗过程。LLM根据Prompt生成候选Payload并发出请求。若请求被WAF拦截，拦截日志将被记录并用于构建下一次的Prompt，迫使LLM改变策略。若请求未被拦截，系统则通过动态分析技术（如监听alert事件）判断漏洞是否被成功触发。整个过程通过不断的“试探-反馈-优化”，使系统能够逐步“学习”并适应特定WAF的防御策略，最终找到能够成功绕过的攻击向量。

4. 核心编排与会话管理模块 (Orchestration Engine) ​

这是整个自动化流程的指挥中心，驱动着测试的每一步迭代。

  • 功能职责:
    • 会话启动/停止: 管理 isRunning 状态，确保分析任务的正确启停。
    • 迭代循环: processAIIteration 方法是核心循环，它按顺序调用AI分析、Payload提取、请求构建、请求发送和结果分析。
    • 状态管理: 使用 AISessionState 类来跟踪当前迭代次数、上一次的AI响应等，管理整个会话的上下文。
    • 对话历史维护: 通过 trimMessageHistory 等方法，管理与AI的对话历史窗口，防止上下文超出Token限制。

5. 数据处理与Payload处理模块 (Data Processing) ​

该模块负责在“AI的语言”和“HTTP的语言”之间进行转换和处理。

  • 功能职责:
    • Payload提取: extractPayloadFromAIResponse 方法根据预设的关键词（如 下一轮payload:）从AI的自然语言回复中精确地提取出XSS Payload。
    • 请求构建: buildFinalRequest 方法将提取到的Payload替换到用户提供的请求模板中的 <xss> 占位符。
    • 格式校验与修复: validateAndFixRequest 和 tryToFixHttpRequestFormat 是非常关键的健壮性设计。它们负责校验AI生成或拼接后的HTTP请求是否合法，并尝试自动修复常见的格式错误（如缺少Host头、错误的Content-Length、不规范的换行符等），确保请求可以被成功发送。
模块 (Module)核心功能 (Core Function)主要方法 / 类 (Key Method / Class)功能说明 (Description)
核心编排与会话管理模块
(Orchestration Engine)		会话启动/停止startAISession()
stopAISession()		初始化并启动AI分析线程，管理 isRunning 标志位，控制UI按钮状态。stopAISession 负责安全地终止循环。
核心迭代循环processAIIteration()驱动整个自动化流程的核心方法。在一个循环中按顺序调用AI通信、Payload处理、请求发送和结果分析，并根据API提供商设置延迟后递归调用自身，实现连续测试。
会话状态管理AISessionState (内部类)存储单次会话的状态，包括迭代次数、上一次AI的响应等，确保迭代之间的上下文连续性。
对话历史维护trimMessageHistory()管理与AI的对话历史（messageHistory）。通过估算Token数量，在每次请求前对历史记录进行裁剪，防止超出API的上下文长度限制。
数据处理与Payload处理模块
(Data Processing)		Payload提取extractPayloadFromAIResponse()
parsePayload()		根据预设的关键词（如 下一轮payload:）和结束标记（--payload-end--），从AI返回的自然语言文本中精确地解析并提取出XSS Payload字符串。
请求构建buildFinalRequest()将提取到的Payload替换到用户预先保存的、包含 <xss> 占位符的HTTP请求模板中，生成最终的攻击请求。
请求格式校验与修复validateAndFixRequest()
tryToFixHttpRequestFormat()		健壮性核心。在发送请求前，严格校验HTTP报文格式（请求行、头部、换行符等），并尝试自动修复常见的格式错误（如缺失Host头、错误的Content-Length），极大提高了AI生成内容的可用性。

研究背景 ​

方面一：Web应用的演进 与 传统扫描技术的困境 ​

  • 现代Web应用的高度复杂化
    • 当前Web应用广泛采用SPA（单页应用）、前后端分离架构，呈现出高动态、富交互的特点，并包含大量复杂的业务流程（如多步注册、在线购物）。
  • 传统扫描器的深度探索瓶颈
    • 传统扫描器依赖链接遍历（Crawling），无法理解和执行由JavaScript事件驱动的、需要按特定顺序操作的业务流。
    • 这导致它们难以触及隐藏在复杂交互背后的深层状态，造成巨大的测试覆盖盲区，大量深层漏洞被遗漏。

方面二：网络攻防对抗的升级 与 静态攻击手段的失效 ​

  • 防御技术的智能化：现代Web应用防火墙（WAF）等安全设备不断升级，能够精准识别和拦截基于固定规则库的、模式固化的攻击请求。
  • 传统扫描器的精准攻击瓶颈：传统扫描器依赖静态Payload库，其攻击特征明显，极易被WAF匹配并拦截，导致高漏报率（假阴性）。这种“一刀切”的攻击方式缺乏针对性和上下文感知能力，产生了大量冗余请求，测试效率低下，且在与智能WAF的对抗中完全处于劣势。

研究目标 ​

总体目标 ​

本研究的总体目标是设计并实现一个基于大型语言模型（LLM）驱动的多智能体协同框架，用于自动化Web渗透测试。该框架旨在系统性地解决传统Web扫描技术在面对现代复杂Web应用时，所暴露出的两大核心瓶颈：深度状态探索覆盖率不足与静态Payload生成易被拦截的问题，并以高发的跨站脚本（XSS）漏洞为典型应用场景进行方法的实现与验证。

具体目标 ​

为实现上述总体目标，本研究将分解为以下三个具体、可行的子目标：

  1. 设计并实现一种任务驱动的智能Web交互方法。
    • 研究如何利用LLM理解Web页面的高级语义，使其能够像人类专家一样自主规划符合业务逻辑的多步操作任务。
    • 实现一个由“感知器-连接器-执行器”构成的智能体交互循环，使其能够精准执行任务，稳定导航至传统爬虫难以触及的深层交互界面。
  2. 设计并实现一种基于LLM的动态Payload生成与对抗方法。
    • 研究如何通过精心设计的提示词（Prompt），将实时攻击上下文与WAF的历史拦截反馈相结合，引导LLM生成具备高针对性和强混淆性的XSS攻击载荷。
    • 实现一个包含“生成-试探-反馈-优化”的闭环对抗学习机制，以提高Payload对WAF的绕过能力和漏洞触发的成功率。
  3. 构建并集成一个多智能体协同的自动化漏洞检测系统。
    • 将上述方法分别封装到任务提取、任务执行、漏洞检测三个功能独立的AI智能体中。
    • 设计并实现三个智能体之间的数据流与协作协议，构建一个从任务定义到漏洞验证的、端到端的自动化测试流水线，并最终完成原型系统的开发与验证。

研究内容 ​

本课题密切围绕现代Web应用中自动化渗透测试的智能化升级需求，针对传统扫描器在深度状态探索和动态攻防对抗方面的双重困境，探究一种基于大型语言模型（LLM）的多智能体协同漏洞检测框架。该框架的有效实现是提升XSS等注入型漏洞自动化发现能力、加固Web应用安全的关键技术。为了实现对Web漏洞的高效与精准挖掘，本课题拟从设计任务驱动的Web交互方法、构建动态Payload生成与对抗模型、开展多维度对比实验与有效性验证三个方面展开研究。

研究内容1：基于任务驱动的Web深度交互方法研究

针对传统扫描器依赖链接遍历、无法理解业务逻辑而导致测试覆盖率严重不足的现状，为了让智能体能够模拟人类专家精准导航至应用的深层交互界面，本研究将设计并实现一种“任务驱动”的Web深度交互方法。首先，将系统性地分析并定义现代Web应用中的交互模式，利用无头浏览器和高效的爬虫接口（例如Playwright），构建一个能够将原始HTML DOM转化为LLM可理解的结构化页面摘要（Page Abstraction）的感知器模块。在此基础上，研究并设计一个以LLM为核心的连接器模块，使其能够根据页面摘要分析出任务目标，然后通过当前页面状态和历史操作，推理并决策出符合逻辑的下一步动作。最终，通过执行器模块将决策转化为对Web浏览器的实际操作，形成“感知-决策-执行”的自主交互闭环，为后续的漏洞检测奠定深入、全面的可达路径基础。

研究内容2：基于大模型的动态Payload生成与对抗方法研究

针对传统扫描器依赖静态Payload库、攻击模式固化且极易被WAF拦截的难题，为了实现对XSS漏洞的精准、高效与高绕过率的检测，本研究将设计并实现一种基于LLM的动态Payload生成与对抗方法。首先，将研究并设计一套专用于Payload生成的提示词工程（Prompt Engineering）策略，该策略能够将攻击点的实时上下文信息与WAF的历史拦截反馈进行整合。在此基础上，构建一个包含“生成-试探-反馈-优化”的闭环对抗学习模型。当攻击被WAF拦截时，系统将拦截日志反馈给LLM，引导其在下一次尝试中生成全新的、具备更强混淆和绕过能力的Payload变体，从而在与WAF的动态博弈中提升漏洞触发的成功率。

研究内容3：多智能体协同检测框架的实现与多维度有效性验证

基于上述研究内容，本研究将实现一个完整的基于任务驱动的多智能体协同自动化Web漏洞检测原型系统，并在包含真实世界应用的多元化测试环境中对其进行系统性的有效性验证。

  1. 系统实现： 将上述方法分别封装到任务提取、任务执行、漏洞检测三个功能独立的AI智能体中，并实现它们之间的数据流与协作协议，构建一个端到端的自动化测试流水线。
  2. 实验环境构建与对比基线选择： 采集并部署包含3个公开靶场和3个真实世界应用的Docker化测试环境，并选取在学术界和工业界具有代表性的扫描工具 Black Widow (2021 SP) 以及经典的 BFS、RandBFS 爬虫算法作为对比基线。
  3. 多维度实验验证：
    • 深度探索能力验证： 在部分测试应用上，将本框架与各基线工具的爬虫覆盖率进行量化对比，以验证本研究在深度状态探索方面的优势。
    • 漏洞检测能力验证： 在全部6个测试应用中，对比本框架与Black Widow扫描器所能发现的XSS漏洞数量，以评估其在无WAF环境下的基础检测效能。
    • WAF绕过能力验证： 为所有测试应用统一部署WAF，再次对比本框架与Black Widow扫描器所能发现的漏洞数量，以验证本研究在智能攻防对抗场景下的实际绕过能力和检测优势。 最终，将通过上述三组对比实验，从覆盖率、检出率和WAF绕过能力等维度，对本原型系统的性能进行量化评估，以证明其方法的先进性与真实可用性。

解决的关键问题 ​

  1. 解决传统扫描器机械遍历与深度状态探索问题 传统Web扫描器依赖于机械式的链接遍历（Link Crawling）算法，本质上只关心页面的URL和表单结构，而对页面的业务逻辑和交互语义一无所知。在现代Web应用中，大量的核心功能由JavaScript事件驱动，并需要用户按照预设的业务流程（如“添加商品-进入购物车-结算”）完成一系列精确的、有序的多步操作。传统的扫描器无法理解“这是一个登录按钮”或“必须先完成第一步才能进入第二步”这类高级语义，因此难以自主执行复杂的操作序列。这导致它们无法触及隐藏在深层交互逻辑背后的攻击面，造成了巨大的测试覆盖盲区。因此，本研究的第一个关键问题是：如何设计并实现一种“任务驱动”的智能导航方法，能够利用大型语言模型（LLM）的语义理解能力，让智能体理解Web应用的业务目标，并自主地规划和执行多步操作序列，从而突破传统爬虫的覆盖率瓶颈，实现对Web应用深层状态的有效探索。
  2. 构建一个能够在动态对抗中达到WAF绕过的智能Payload生成模型 即便能够到达深层输入点，传统扫描器的攻击手段也面临着严峻挑战。它们通常依赖一个庞大但静态的、基于签名的Payload规则库，在攻击时进行大量的注入尝试。这种方式存在两大缺陷：首先，它缺乏对注入点上下文的感知，无法生成针对性的攻击向量，导致大量无效请求；其次，其固化的攻击模式极易被现代Web应用防火墙（WAF）的规则库精准识别并拦截，造成极高的漏报率（假阴性）。因此，本研究的第二个关键问题是：如何设计一种新颖的、具备动态对抗能力的Payload生成模型，能够利用LLM的推理与代码生成能力，实时地结合注入点上下文和WAF的历史拦截反馈，动态地、迭代地生成具备高针对性的定制化XSS攻击载荷。

近期研究进展 ​

基于任务驱动的深度交互方法 ​

感知器模块 ​

将一个复杂的、动态的网页 DOM 结构，转换成一个简化的、结构化的文本表示 abstractPage ，这个表示只包含与任务执行最相关的可交互元素。这个简化的文本可以被大型语言模型（LLM）高效地理解和处理。该模块包含的核心方法/结构及其功能作用如下表所示：

核心方法/结构功能作用
Sensors 类整个模块的容器。负责实例化一个传感器对象，该对象能够感知网页内容并将其转换为抽象表示。
constructor(pageWrapper)构造函数。初始化 Sensors 实例，保存对 pageWrapper 对象的引用（用于与浏览器页面交互），并初始化 abstractPage 属性为空字符串。
getAbstractPage()获取器 (Getter)。一个简单的公共方法，用于返回当前生成的、最新的页面抽象表示字符串 (abstractPage)。
async updateAbstractPage()核心协调方法。这是 Sensors 的主要工作函数。它负责：
1. 调用 pageWrapper 获取所有可交互元素（可点击元素、表单）。
2. 清空旧的 abstractPage。
3. 遍历获取到的元素，为每个元素生成唯一 ID 并调用相应的 ...ToString 方法。
4. 将所有元素的字符串表示拼接起来，完成 abstractPage 的更新。
async clickableToString(elem, id)字符串转换器。将一个可点击的浏览器元素对象转换为一个简化的、类似 HTML 的字符串。例如，<button id=0>登录</button>。它提取标签名、内部文本，并嵌入由 actionsMapping 分配的唯一 ID。
async inputFieldToString(elem, id)字符串转换器 (当前未使用)。将一个输入框元素对象转换为包含其类型、名称、标签等信息的字符串。
async formToString(elem, id)字符串转换器。将一个表单 (<form>) 元素对象转换为一个简化的开始标签字符串，包含其名称、提交地址 (action)、方法 (method) 以及唯一的 ID。例如，<form id=5 name="loginForm" ...>。
这个过程可以分解为以下几个关键步骤：
  1. 收集元素 (Gather Elements): 通过 page-wrapper.js 从当前浏览器页面中获取所有重要的可交互元素。在当前代码中，这主要是两类：
    • 可点击元素: 包括链接 (<a>)、按钮 (<button>)、提交输入 (<input type="submit">) 等。这是通过 pageWrapper.getUniqueClickables() 实现的。
    • 表单元素: 即 <form> 标签。这是通过 pageWrapper.getForms() 实现的。
  2. 状态重置 (Reset State): 在处理新获取的元素之前，必须清空上一次的状态。这包括：
    • 清空 this.abstractPage 字符串。
    • 调用 actionsMapping.clear()] 清空旧的 ID 与页面元素的映射关系，确保 ID 只与当前页面的元素对应。
  3. 处理并转换元素 (Process and Transform Elements): 这是流程的核心。程序会遍历第一步收集到的每个元素，并执行两个关键操作：
    • 注册并获取ID: 对于每个元素（无论是可点击元素还是表单），都会调用 actionsMapping.addAction(elem, type)。这个函数会将真实的浏览器元素对象存储起来，并返回一个唯一的、从 0 开始递增的数字 ID。这个 ID 成为了抽象表示和真实元素之间的桥梁。
    • 转换为字符串: 根据元素的类型，调用相应的 ...ToString() 方法（如 clickableToString 或 formToString）将元素转换为一个简化的、类似 HTML 的字符串。这个字符串会包含元素的标签名、关键属性（如 name, action）以及最重要的——刚刚获取的那个唯一 ID。
  4. 构建抽象页面 (Build Abstract Page): 将上一步生成的每个元素的字符串表示，逐一追加到 this.abstractPage 属性中，每个元素占一行。
  5. 完成: 当所有元素都处理完毕后，updateAbstractPage() 方法执行结束。此时，sensors 实例就持有了当前页面的最新文本快照，可以被其他模块（如 llm-bridge）获取和使用。

连接器模块 ​

这个模块负责将 Sensors 模块收集到的信息（状态）和 Tasks 模块提供的任务打包成一个 LLM 能够理解的提示（Prompt），然后将这个提示发送给 LLM API，最后接收并返回 LLM 的决策（下一步的动作）。该模块包含的核心方法/结构及其功能作用如下表所示：

核心方法/结构功能作用
LLMBridge 类整个连接器模块的容器。负责管理与 LLM 的所有交互，包括配置、历史记录、API 调用和错误处理。
constructor(id, template)构造函数。初始化实例，包括：
1. 设置聊天记录文件的路径。
2. 根据命令行参数 (--model, --gpt4) 确定使用的模型名称。
3. 关键: 根据命令行参数 (--manual, --model-endpoint) 初始化 OpenAI 客户端，可以指向官方 API 或自定义的代理 URL。
async requestApi(prompt)核心公共方法。接收一个格式化好的提示（Prompt），负责协调整个与 LLM 的交互流程：构造消息历史、检查 Token、调用 API、记录结果，并最终返回 LLM 的回复。
async _performApiCall(messages)API 调用执行器。实际向 LLM API 发送请求的地方。包含了完整的 try...catch 错误处理和重试逻辑，以应对网络波动或 API 临时故障，保证了交互的健壮性。
async _performManualCall(prompt)手动模式执行器。在手动模式下替代 _performApiCall。它将提示输出到控制台，并等待用户手动输入回复，用于调试和模拟 LLM 行为。
_checkTokenLimit(messages)Token 限制检查器。在发送 API 请求前，使用 gpt-tokenizer 库确保消息历史的总长度没有超过模型的最大 Token 限制。如果超限，则调用 _reduceTokenCount 进行削减。
_reduceTokenCount(messages)Token 削减器。当 _checkTokenLimit 发现 Token 超限时，此方法负责从消息历史的开头移除最旧的消息，以满足 Token 限制要求。
_writeConversationToFile(prompt, reply)对话记录器。将每一次的请求（Prompt）和响应（Reply）追加写入到 Markdown 文件中，用于后续的分析、审计和调试。
chatHistory (属性)上下文管理器。一个数组，存储了整个任务执行过程中的所有对话历史。它是实现多轮对话、让 LLM 理解上下文的关键。

  1. 构造消息历史 (Construct Messages):

    • 交互不是一次性的，LLM 需要上下文才能做出连贯的决策。因此，requestApi 首先会从 this.chatHistory 中提取最近的几条对话记录（数量由 config.includedChatHistoryLength 定义）。
    • 然后，它将当前由其他模块（如 main-module.js）生成的新提示（prompt）包装成一个标准的用户消息对象（{ role: 'user', content: ... }）。
    • 最后，将新提示追加到历史消息的末尾，形成一个完整的对话消息数组 messages。

  2. 检查 Token 限制 (Check Token Limit):

    • LLM 模型有输入长度限制（Token Limit）。在发送请求前，必须确保 messages 数组的总长度没有超限。
    • 程序会调用 _checkTokenLimit 方法，该方法使用 gpt-tokenizer 库来计算当前消息的总 Token 数。
    • 如果超限，它会进入一个循环，不断调用 _reduceTokenCount 方法，从 messages 数组的开头（即最早的对话历史）移除消息，直到总 Token 数符合限制为止。这是一种“滑动窗口”策略，保留最新的上下文，丢弃最旧的。

  3. 执行 API 调用 (Perform API Call):

    • 这是流程的核心。程序会调用私有方法 _performApiCall(messages)。
    • 该方法使用 openai 库的 this.openai.chat.completions.create() 来向配置好的 LLM API 端点（可以是 OpenAI 官方，也可以是你的代理地址）发送请求。
    • 健壮性设计: 这个调用被包裹在一个带有重试逻辑的 for 循环中。如果 API 请求因为网络问题或服务器临时错误而失败（例如超时），它会等待一小段时间然后重试，最多重试 config.maxRetries 次。

  4. 记录与返回 (Log and Return):

    • 一旦成功从 LLM API 获取到回复（reply），程序会调用 _writeConversationToFile 方法，将本次的提示（prompt）和回复（reply）追加写入到 chat-histories 目录下的一个 Markdown 文件中。这对于调试和审计至关重要。
    • 同时，新的提示和回复也会被添加到 this.chatHistory 数组中，为下一次交互提供上下文。
    • 最后，方法将 LLM 的回复字符串返回给调用者（通常是 main-module.js），以供 actuators.js 解析和执行。

执行器模块 ​

它接收来自 llm-connect的抽象指令（如 "CLICK 3"），并将其精确地翻译成在浏览器中执行的具体动作。该模块包含的核心方法/结构及其功能作用如下表所示：

核心方法/结构功能作用
Actuators 类整个执行器模块的容器。负责将 LLM 生成的抽象指令转换为具体的浏览器操作。
constructor()构造函数。初始化实例，并注入所有它需要依赖的模块，如 sensors, pageWrapper (底层驱动), tasksModule (任务管理器), screenshotModule (调试工具) 等。
async parseAbstractAction(absAction)核心公共方法。接收一个来自 LLM 的指令字符串（如 "CLICK 3"），并负责协调整个解析、验证、分发和执行的流程。
async handleClickCommand()专门处理 CLICK 指令。它包含类型检查、截图、调用 pageWrapper 点击元素、记录历史等一系列操作。
async handleFormCommand()专门处理 FILL & SUBMIT FORM 指令。它负责调用 formModule 进行填充，截图，然后调用 pageWrapper 提交表单。
completedStepsHistory历史记录器。一个数组，用于存储当前任务已经成功执行的所有步骤的文本描述。这对于调试和最终生成报告非常有用。
getCompletedStepsHistory()用于从外部获取已完成步骤的历史记录。

  1. 解析和验证 ID (Parse and Validate ID):

    • LLM 返回的指令格式是 COMMAND <ID> ...，例如 CLICK 3。流程的第一步是从这个字符串中提取出数字 ID。它使用正则表达式 /\d+/ 来找到第一个数字。
    • 健壮性检查:
      • 如果字符串中找不到数字，说明指令格式错误，直接返回 false。
      • 获取到 ID 后，会调用 actionsMapping.isValidId(id) 来验证这个 ID 是否有效（即，是否存在于当前页面的元素映射中）。如果 LLM 幻想出了一个不存在的 ID，这一步可以防止程序出错，并返回 false。

  2. 翻译 ID 为真实元素 (Translate ID to Real Element):

  3. 解析命令并分发 (Parse Command and Dispatch):

    • 程序检查 absAction 字符串的开头，以确定具体要执行哪种命令。
    • 如果指令以 click 开头，它会将 ID 和元素对象传递给私有方法 #handleClickCommand 进行处理。
    • 如果指令以 fill 开头（在当前版本中是 FILL & SUBMIT FORM），它会将 ID 和元素对象传递给私有方法 #handleFormCommand 进行处理。
    • 如果指令无法识别，则返回 false。

  4. 执行具体动作 (Execute Specific Action):

    • #handleClickCommand:
      1. 类型检查: 确认目标元素的类型是 'clickable'。如果 LLM 错误地让它去点击一个表单，它会记录错误并返回 false。
      2. 执行前操作: 调用 screenshotModule 对即将被点击的元素进行截图，用于调试和记录。
      3. 核心执行: 调用 this.pageWrapper.clickElement(selectedElem)，这会触发 page-wrapper.js 中封装好的、健壮的点击逻辑。
      4. 执行后操作: 将本次操作记录到 completedStepsHistory 中，并调用 evaluationModule 执行评估测试。
    • #handleFormCommand:
      1. 类型检查: 确认目标元素的类型是 'form'。如果 LLM 试图在一个按钮上执行表单填充，它会记录错误并返回 false。
      2. 核心执行:
        • 调用 this.formModule.fillForm(selectedElem)，这个独立的模块负责处理复杂的表单填充逻辑（它内部可能再次与 LLM 交互以生成填充内容）。
        • 填充完毕、提交之前，调用 screenshotModule 对整个表单进行截图。
        • 调用 this.pageWrapper.submitForm(selectedElem) 提交表单。
      3. 执行后操作: 记录操作历史并调用评估模块。

  5. 返回结果 (Return Result):

    • 如果整个流程（包括类型检查和实际执行）都成功，方法返回 true。
    • 在任何一个环节失败，方法返回 false。这个布尔返回值会告诉上层的主循环，当前步骤是否成功执行。

基于大模型的PayLoad生成方法 ​

该方法的工作流程是一个闭环的对抗过程，具体分解为以下三个阶段：

  1. 阶段一：初始化与首次试探 (Initial Probe)

这是智能体与目标建立初次交互并进行基线测试的阶段。

  • 构建初始上下文:
    • 系统指令 (System Prompt): 智能体首先加载一个包含专家知识的系统级提示（INITIAL_PROMPT）。这个Prompt定义了它的角色（XSS专家）、任务目标（绕过WAF）、必须遵守的规则（如Payload格式、禁止使用的关键词）以及关于WAF拦截模式的先验知识（如常见拦截正则、绕过技术）。
    • 初始观测 (Initial Observation): 智能体接收用户提供的初始HTTP请求和响应（来自requestTextArea和responseTextArea），这构成了它对目标的第一次观测。
  • 生成首次候选Payload:
    • 在 startAISession 方法中，系统指令和初始观测被打包成第一个发送给LLM的请求。
    • LLM根据这些信息，生成第一个候选的XSS Payload。
  • 执行首次试探:
  1. 阶段二：反馈收集与分析 (Feedback Analysis)

在每次试探后，智能体必须精确地理解试探的结果，这是优化的前提。

  • 收集反馈: 智能体接收到目标返回的HTTP响应。
  • 分析反馈 (启发式判断): 在 processValidRequest 方法中，智能体对反馈进行分析，这是反馈循环的关键。
    • 负反馈 (Negative Feedback - WAF拦截):
      • 智能体检查响应状态码是否为 403, 400 等典型的拦截码。
      • 同时，通过 isWafIntercepted 方法检查响应内容是否包含 "waf", "拦截", "安全狗" 等关键词。
      • 如果识别为WAF拦截，智能体会生成一个高度浓缩的负反馈信息，例如：“HTTP Response: 403 已经判断为被WAF拦截，请你重新生成payload尝试绕过waf...”。它不会将完整的请求和响应再次发送给LLM，从而节省Token并给出强烈的指导信号。
    • 正反馈/中性反馈 (Positive/Neutral Feedback - 未拦截):
      • 如果状态码正常（如200 OK）且未检测到WAF关键词，智能体认为本次试探至少在网络层面是成功的。
      • 此时，它会将本次使用的攻击请求和目标返回的完整响应（经过truncateContent截断以控制长度）打包，作为下一次优化的详细依据。
  1. 阶段三：迭代优化与再试探 (Iterative Optimization & Re-Probe)

这是智能体根据反馈进行“学习”和“进化”的阶段，体现了其智能性。

  • 构建优化Prompt:
    • 智能体将上一阶段分析得出的反馈（无论是浓缩的负反馈还是详细的正反馈）作为新的"user"消息。
    • 通过 trimMessageHistory 方法管理整个对话历史，确保上下文的连贯性，同时避免超出LLM的Token限制。这个包含“系统指令 + 历史交互 + 最新反馈”的完整上下文，构成了一个用于优化的新Prompt。
  • 生成优化Payload:
    • 这个新的Prompt被发送给LLM。由于Prompt中包含了明确的反馈（“你上次的尝试被拦截了，换个思路”或“你上次的尝试未被拦截，请基于这个结果继续分析”），LLM被引导生成一个策略不同、更具针对性的新Payload。
  • 执行再试探:
    • 智能体重复阶段一的最后步骤：提取、构建、校验、发送新的攻击请求。

这个 “试探 -> 反馈 -> 优化” 的闭环在 processAIIteration 方法的递归调用中不断进行，直到用户手动停止。每一次循环，智能体都在与WAF进行一次博弈，并根据结果调整策略，逐步逼近能够成功绕过防御并触发漏洞的最终解。

UPDATE 本研究设计并实现了一个包含“试探-反馈-优化”的闭环迭代工作流。该工作流是漏洞检测智能体的核心引擎，它通过模拟安全专家的思考过程，在与目标WAF的对抗中不断调整攻击策略。其具体实现可分解为以下三个关键阶段：

  1. 阶段一：初始化与首次请求：该阶段的目标是为智能体建立初始的攻击上下文，并执行第一次基线测试。首先，通过加载一个包含专家知识的系统级提示（System Prompt），为智能体设定其角色（XSS专家）、任务目标（绕过WAF）以及关于WAF绕过技术和规则的先验知识。随后，智能体将用户提供的初始HTTP请求与响应作为其对目标的“初始观测”。基于这些初始信息，LLM生成第一个候选XSS Payload。最后，系统将此Payload嵌入原始请求模板中，经过格式校验与自动修复后，向目标发送首次攻击试探，从而启动整个对抗循环。
  2. 阶段二：反馈收集与分析：在每次试探后，智能体必须精确地理解试探的结果，这是后续优化的前提。该阶段的核心是基于启发式规则对HTTP响应进行判断。
    • 负反馈（WAF拦截）的识别： 智能体通过检查响应状态码（如 403, 400 等）和响应体内容中的特定关键词（如 "waf", "拦截", "安全狗" 等），来判断本次请求是否被WAF拦截。若判断为拦截，系统将生成一条高度浓缩的负反馈指令（如“已被WAF拦截，请更换思路”），以强信号引导LLM进行策略调整。
    • 正反馈/中性反馈（未被拦截）的识别： 若响应状态码正常且未检测到WAF关键词，智能体则认为本次试探在网络层面成功。此时，它会将本次使用的攻击请求和目标返回的完整响应进行打包，作为下一次迭代优化的详细依据。
  3. 阶段三：迭代优化与再次请求：智能体将上一阶段分析得出的反馈信息（负反馈和正反馈）作为新的用户消息，与完整的对话历史相结合，构建出一个用于优化的新Prompt。这个包含了“系统指令 + 历史交互 + 最新反馈”的完整上下文被再次发送给LLM。由于Prompt中包含了明确的结果反馈，LLM被引导生成一个策略不同、更具针对性的新Payload。随后，智能体重复执行“提取-构建-校验-发送”的再试探流程。这个“试探 -> 反馈 -> 优化”的闭环在系统中不断递归进行，使智能体在每一次循环中都在与WAF进行一次新的对抗，并根据结果调整策略，逐步逼近能够成功绕过防御并触发漏洞的最终解。

阶段一：初始化与首次请求 ​

这个阶段是整个动态对抗的起点，其核心任务是建立智能体（Agent）对目标的初始认知，并根据这个认知发起第一次攻击尝试。该阶段包含的核心方法/结构及其功能作用如下表所示：

核心方法 / 结构功能作用
初始上下文 (Input)提供智能体执行任务所需的所有初始信息，包括攻击模板和目标的基线行为。
INITIAL_PROMPT (String)智能体核心指令集: 定义了智能体的角色、目标和行为准则，是其所有决策的基础。
messageHistory (List)动态工作记忆: 存储和管理智能体的思考过程。在此阶段，它被初始化并装载了核心指令和初始观测。
truncateContent()信息压缩器: 在消化初始观测时，对信息进行压缩，以聚焦关键内容并符合LLM的输入限制。
LLM 交互接口决策核心/大脑: 接收智能体的工作记忆，并根据其推理能力生成新的攻击策略（Payload）。
extractPayloadFromAIResponse()策略解析器: 从LLM的自然语言响应中，精确提取出结构化的、可执行的攻击载荷。
buildFinalRequest()攻击向量构造器: 将抽象的攻击载荷与请求模板结合，生成具体的攻击向量（HTTP请求）。
validateAndFixRequest()攻击向量校验器: 保证生成的攻击向量在技术上是有效的，符合HTTP协议规范，是执行试探前的最后一道质量关。
HTTP请求/响应接口负责执行最终的动作——将构造好的攻击向量发送到目标，并接收其反馈。
  1. 上下文获取 : 流程启动。智能体被赋予一个初始上下文。这个上下文包含：
    • 一个请求模板 ：这是一个包含特殊注入标记 <xss> 的HTTP请求。
    • 一个初始观测 ：一对初始的HTTP请求及其对应的响应，这代表了目标的基线行为。
  2. 智能体初始化 : 智能体为执行任务进行内部准备。
    • 加载核心指令: 智能体加载其内置的、不可变的系统级提示 INITIAL_PROMPT。这个指令集定义了它的专家角色、任务目标、行为准则和先验知识。
    • 构建初始记忆: 智能体初始化其对话记忆，并将核心指令作为第一条系统消息存入。
    • 消化初始观测: 智能体将“初始观测”中的请求和响应，经过truncateContent信息压缩，格式化为一条用户消息，并存入其对话记忆中。
  3. 首次策略生成: 智能体基于其初始记忆，思考并生成第一个攻击策略。
    • 请求策略: 智能体将其完整的初始记忆（包含系统指令和初始观测）发送给大语言模型（LLM），请求生成一个攻击策略。
    • 接收并解析策略: 智能体接收LLM的响应，并调用 extractPayloadFromAIResponse方法，从自然语言回复中解析出结构化的攻击载荷。
  4. 攻击向量构建与校验: 智能体将抽象的策略转化为一个具体的、可执行的攻击。
    • 构建向量: 调用 buildFinalRequest 方法，将解析出的Payload精确地注入到请求模板的 <xss> 标记处，生成一个完整的攻击向量，即一个全新的HTTP请求。
    • 格式校验: 在执行前，调用 validateAndFixRequest 方法对这个新生成的攻击向量进行严格的HTTP协议格式校验，并自动修复常见错误，如Content-Length不匹配，确保其技术上的有效性。
  5. 执行首次试探: 智能体通过其统一的HTTP请求/响应接口将经过校验的攻击向量发送至目标，完成第一次试探。这个动作的结果将作为下一阶段反馈分析的输入。

阶段二：反馈收集与分析 ​

这个阶段是“试探-反馈-优化”循环的核心，它负责将上一步试探的结果转化为LLM能够理解的、用于指导下一步优化的反馈。该阶段包含的核心方法/结构及其功能作用如下表所示：

核心方法 / 结构功能作用
processValidRequest()反馈处理中心: 接收HTTP响应，并编排整个分析和决策流程。
callbacks.makeHttpRequest()反馈收集器: 实际执行HTTP请求并从目标服务器获取原始响应数据。
helpers.analyzeResponse()响应解析器: 从原始响应字节中提取出结构化信息，主要是HTTP状态码。
isWafIntercepted()WAF指纹检测器: 通过关键词匹配，对响应内容进行启发式分析，判断是否存在WAF拦截指纹。
if-else 决策逻辑反馈分类器: 整个阶段的核心。根据状态码和WAF指纹，将反馈分为“负反馈”和“中性/正反馈”两个分支。
simplifiedUserContent (String)负反馈模板: 当检测到WAF拦截时，用于生成一个简短、明确的指令，告诉LLM尝试失败，需要改变策略。
nextUserContent (String)详细上下文模板: 当未检测到拦截时，用于打包详细的请求和响应信息，供LLM进行深度分析。
truncateContent()信息压缩器: 在构建详细上下文时，对请求和响应进行截断，以在保留关键信息和控制Token消耗之间取得平衡。
messageHistory.add()记忆更新器: 将分析和决策后生成的反馈信息，作为新的用户输入添加到对话历史中，为下一阶段的优化做准备。
核心流程分析
  1. 接收反馈 : 在 processValidRequest 方法中，智能体通过 callbacks.makeHttpRequest 发送攻击请求后，会接收到目标服务器返回的原始HTTP响应（IHttpRequestResponse）。这是最直接、最原始的反馈数据。
  2. 初步解析: 智能体立即使用 helpers.analyzeResponse 对响应字节流进行解析，提取出两个最关键的初步指标：
    • HTTP状态码 (Status Code): 如 200, 403, 500 等。
    • 响应体内容 (Response Body): 完整的HTML或文本内容。
  3. 启发式分析与决策 : 这是此阶段的核心决策点。智能体根据预设的启发式规则，对反馈进行分类。
    • 路径A：判定为负反馈 (Negative Feedback - WAF拦截)
      • 触发条件: if (status == 403 || status == 400 || ... || isWafIntercepted(responseText))
        • 条件1 (强信号): 响应状态码是 403, 400, 502, 500 等典型的拦截或错误码。
        • 条件2 (弱信号): 调用 isWafIntercepted(responseText)方法，检查响应体内容是否包含 "waf", "拦截", "安全狗", "宝塔" 等明确的WAF指纹关键词。
      • 决策动作: 如果满足任一条件，智能体判定本次攻击被WAF拦截。它会构造一个高度概括、指令明确的简化信息（simplifiedUserContent），例如：“HTTP Response: 403 已经判断为被WAF拦截，请你重新生成payload尝试绕过waf...”。这个信息直接告诉LLM“你失败了，换个思路”，而不提供完整的请求和响应细节，以节省Token并进行强力引导。
    • 路径B：判定为中性/潜在正反馈 (Neutral/Potential Positive Feedback - 未拦截)
      • 触发条件: 不满足路径A的所有条件，通常意味着响应状态码为 200 OK。
      • 决策动作: 智能体认为本次攻击至少在网络层面成功绕过了WAF。为了让LLM能进行更精细的分析（例如判断Payload是否被转义、是否破坏了HTML结构），它会构造一个包含详细上下文的信息。这个信息包括了本次发送的、经过truncateContent截断的攻击请求全文和目标响应全文。
  4. 更新对话历史 (Update Conversation History): 无论决策走向哪个路径，最终生成的反馈信息（简化的或详细的）都会被包装成一个 role: "user" 的 JSONObject，并添加到 messageHistory 列表中。这确保了LLM在下一次生成Payload时，能够看到上一次尝试的结果，从而形成闭环。

阶段三：迭代优化与再次请求 ​

这个阶段是整个智能体学习和进化的核心。它接收上一阶段分析好的反馈，利用LLM的推理能力生成一个更优的策略（Payload），并发起新一轮的试探，从而形成一个完整的“试探-反馈-优化”闭环。该阶段包含的核心方法/结构及其功能作用如下表所示：

核心方法 / 结构功能作用
processAIIteration()循环驱动器: 整个迭代优化的主循环方法，通过递归调用自身来驱动一轮又一轮的“优化-再试探”过程。
messageHistory (List)动态记忆库: 存储着完整的、经过裁剪的对话上下文。它就是发送给LLM的、用于指导优化的核心Prompt。
trimMessageHistory()记忆管理器: 核心的上下文管理工具。通过滑动窗口机制，在保留关键信息和防止Token超限之间取得平衡，确保长期对话的有效性。
sendTo...AI()优化请求器: 将 messageHistory 作为输入，请求LLM根据历史反馈生成一个新的、更优的策略（Payload）。
extractPayloadFromAIResponse()Payload解析器: 从LLM的优化建议中提取出可执行的新Payload。
buildFinalRequest()攻击构造器: 将新Payload注入模板，构建新一轮的攻击请求。
validateAndFixRequest()确保新一轮的攻击请求在发送前是格式正确的。
processValidRequest()再试探执行器: 发送新的攻击请求，并触发下一轮的“阶段二：反馈收集与分析”。
  1. 进入优化阶段: 将上一轮的反馈（无论是简化的负反馈还是详细的中性反馈）添加到 messageHistory 之后，processAIIteration 方法的循环会继续。
  2. 上下文管理: 确保长期对话有效性的关键步骤。
    • 功能: 该方法像一个滑动窗口，它会裁剪 messageHistory，确保总Token数不超过 MAX_TOKEN_LIMIT。
    • 策略: 它始终保留第一条系统指令 (System Prompt)，然后从最新的对话开始，向前保留尽可能多的交互历史。这确保了LLM总能看到最近几次的尝试及其结果，这是进行有效迭代优化的基础。
  3. 构建优化Prompt :
    • 经过 trimMessageHistory 处理后的 messageHistory本身，就是一个结构化的、用于优化的新Prompt。
  4. 请求优化策略 :
    • processAIIteration 方法调用相应的 sendTo...AI() 方法。
    • 这个方法将 messageHistory 序列化为JSON格式，通过API发送给LLM。由于Prompt中包含了明确的反馈，LLM被引导去生成一个与之前不同的、更可能绕过防御的新Payload。
  5. 执行再试探 :
    • 智能体接收到LLM返回的包含新Payload的响应。
    • 接下来的流程与“阶段一”的后半部分完全相同，形成了一个可重复的模式.
  6. 循环: 新的试探完成后，流程自然地再次进入“阶段二：反馈收集与分析”，然后再次进入“阶段三”，如此循环往复，直到停止。

实验 ​

类别应用名称架构/技术特点在你实验中的核心价值
真实世界应用OpenCartPHP, MVC真实的电商业务流程
GitLabRuby on Rails, SPA极其复杂的 DevOps 平台，深层状态多
MoodlePHP复杂的在线教育平台，用户角色和权限多
公开测试靶场OWASP Juice ShopNode.js, Angular (SPA)检验对现代SPA应用的深度探索能力
DVWAPHP (传统渲染)提供分级难度，检验基础检测与绕过能力
PortSwigger Labs (复现)各种技术栈提供专业、前沿的WAF绕过场景，检验Payload生成极限
测试靶场漏洞/挑战描述Task-driven Agent (本研究)Black Widow分析与原因
OWASP Juice ShopDOM-XSS in Search Bar (通过URL Fragment /#/search?q=<...> 注入)发现未发现[深度探索优势] Juice Shop是SPA应用，其路由由前端JavaScript管理。Black Widow无法理解/#/的哈希路由，几乎无法发现除首页外的任何页面和功能。而本研究的智能体能理解搜索框是可交互元素并执行“搜索”任务，从而发现此漏洞。
Stored-XSS in Product Review (需要登录->导航到商品->提交评价)发现未发现[深度探索优势] 此漏洞隐藏在一个需要多步、有状态操作才能到达的深层界面。Black Widow无法自主完成“登录并发表评价”的业务流。本研究的智能体通过执行预设任务，成功导航至目标输入点并注入Payload。
DVWA (Low Security)Reflected-XSS in "Name" field (无任何过滤)发现发现[基线能力验证] 在无任何防护的理想情况下，两种工具都能通过基本Payload发现漏洞。这证明了本研究方法在基础场景下的有效性。
DVWA (High Security)Reflected-XSS in "Name" field (服务端过滤了<script>标签)发现未发现[动态Payload优势] Black Widow的静态Payload（如<script>alert(1)</script>）被服务端过滤，导致漏报。本研究的智能体在首次尝试失败后，LLM根据上下文生成了绕过Payload（如<img src=x onerror=alert(1)>），成功触发漏洞。
PortSwigger LabsReflected-XSS with event handlers blocked (服务端黑名单过滤了所有on*事件处理器)发现未发现[动态Payload优势] 这是一个高级绕过场景。Black Widow的Payload库中所有依赖onerror, onclick的攻击都将失败。本研究的智能体在多次试探并收到负反馈后，LLM从其知识库中选择并生成了非事件处理器的向量，如<svg><a xlink:href="javascript:alert(1)"><rect width="100" height="100" /></a></svg>，成功绕过。
DOM-XSS with > and < encoded (前端JS对尖括号进行了HTML实体编码)发现未发现[动态Payload优势] 此场景下，所有包含HTML标签的Payload都会失效。Black Widow无能为力。本研究的智能体通过分析注入点位于JS代码中的上下文，生成了不依赖尖括号的Payload（如'-alert(1)-'），成功闭合字符串并执行了JS代码。

本节旨在通过一系列系统性的、可复现的实验，对本文提出的基于任务驱动的Web漏洞扫描智能体的有效性、先进性与实用价值进行全面的量化评估。实验围绕本研究拟解决的两大关键问题深度状态探索与动态攻防对抗进行设计，旨在达成以下三个核心目的：

  1. 验证深度探索能力： 通过在OpenCart、GitLab、Moodle等大型真实世界Web应用上进行爬虫覆盖率对比实验，旨在定量地证明本框架所采用的“任务驱动”交互方法，相较于传统的链接遍历算法（如BFS、RandBFS）及工具（如Black Widow），能够在多步、有状态的复杂业务流程中发现更深层次的交互状态。
  2. 评估基础漏洞检测的能力： 通过在包含公开靶场和真实应用的多元化测试环境中，与业界代表性工具Black Widow进行XSS漏洞检测对比，评估本框架在无WAF防护的基础场景下的基线检测能力。
  3. 检验动态对抗与WAF绕过能力： 通过为所有测试环境统一部署WAF，并再次与Black Widow进行漏洞检测对比，验证本框架基于LLM的动态Payload生成方法在真实攻防对抗场景下的能力。

5.2.3 对比基线选择 ​

为客观评估本框架的性能，我们选取了以下具有代表性的算法与工具作为对比基线：

  • Black Widow (2021 SP): 一款在学术界和工业界均有广泛应用的Web扫描器，它代表了基于链接遍历的传统自动化扫描技术。
  • BFS (广度优先搜索) & RandBFS (随机广度优先搜索) 爬虫: 两种最经典的页面遍历算法。将本框架与这两种基础算法进行对比，旨在从算法层面更纯粹地衡量“任务驱动”方法在探索效率与深度上的提升。

5.2.4 实验设计 ​

围绕本研究的三个核心目的，我们设计了以下三组层层递进的对比实验：

  1. 实验一：覆盖率验证
    • 目标： 定量评估本框架“任务驱动”方法在探索深度上的优势。
    • 对象： 选用OpenCart, GitLab, Moodle三个真实世界应用
    • 方法： 分别使用本框架、Black Widow、BFS爬虫及RandBFS爬虫对三个应用进行扫描，统计并对比各方法所能发现的唯一页面状态（或可交互输入点）的数量。
  2. 实验二：基础漏洞检测效能评估
    • 目标： 在无WAF防护的基准环境下，评估本框架的XSS漏洞检测能力。
    • 对象： 使用全部6个Web应用，以覆盖多样化的场景。
    • 方法： 使用本框架与Black Widow进行XSS漏洞扫描，对比两者发现并确认的XSS漏洞总数。
  3. 实验三：动态对抗（WAF绕过）能力检验
    • 目标： 在模拟真实攻防对抗的环境下，核心检验本框架动态Payload生成模块的WAF绕过能力。
    • 对象： 选用OpenCart, GitLab, Moodle三个真实世界应用，以模拟对生产环境的渗透测试。
    • 方法： 为上述三个应用统一前置部署宝塔WAF（Pagoda WAF）。在此防护环境下，再次使用本框架与Black Widow进行XSS漏洞扫描，对比两者在WAF开启后仍能成功发现的XSS漏洞数量。

本节旨在通过一系列系统性的、可复现的实验，对本文提出的基于任务驱动的Web漏洞扫描智能体的有效性、先进性与实用价值进行全面的量化评估。实验围绕本研究拟解决的两大关键问题深度状态探索与动态攻防对抗进行设计，旨在达成以下三个核心目的：

  1. 验证深度探索能力： 通过在OpenCart、GitLab、Moodle等大型真实世界Web应用上进行爬虫覆盖率对比实验，旨在定量地证明本框架所采用的“任务驱动”交互方法，相较于传统的链接遍历算法（如BFS、RandBFS）及工具（如Black Widow），能够在多步、有状态的复杂业务流程中发现更深层次的交互状态。

  2. 评估基础漏洞检测的能力： 通过在包含公开靶场和真实应用的多元化测试环境中，与业界代表性工具Black Widow进行XSS漏洞检测对比，评估本框架在无WAF防护的基础场景下的基线检测能力。

  3. 检验动态对抗与WAF绕过能力： 通过为所有测试环境统一部署WAF，并再次与Black Widow进行漏洞检测对比，验证本框架基于LLM的动态Payload生成方法在真实攻防对抗场景下的能力。

菜就多练

Copyright © 2025-2026

本站访客数 人次 本站总访问量 次