文章总结： 文档介绍YURASCANNER，一种任务驱动的大语言模型Web漏洞扫描方法。它通过将扫描器建模为智能体，利用LLM引导导航，解决传统工具难以深入复杂业务流程的痛点。实验显示其在攻击面覆盖与漏洞发现上表现优异，能有效挖掘深层漏洞。虽存在依赖前置状态及成本高等局限，但建议作为复杂场景的辅助工具。 综合评分： 85 文章分类： WEB安全,AI安全,安全工具,漏洞分析,渗透测试

论文研读与思考|YURASCANNER：一种基于任务驱动的大语言模型Web漏洞扫描方法

QIU QIU

玄枢战队-Arcane Hub

2026年3月9日 18:18 陕西

原文标题：《YURASCANNER: Leveraging LLMs for Task-driven Web App Scanning》

原文作者：Aleksei Stafeev, Tim Recktenwald, Gianluca De Stefano, Soheil Khodayari, Giancarlo Pellegrino

会议： Network and Distributed System Security Symposium (NDSS 2025)

一、主要研究问题

1.1 核心研究问题和研究动机

做过Web漏洞扫描的人，大多都有类似的体验：扫描器跑了很久，结果看起来不少，但真正值得花精力分析的问题并不多。原因其实不复杂。现在的Web应用早就不是点几个链接、交几个表单那么简单了，很多功能都被包在多步业务流程里，比如先创建对象、配置参数、保存之后才能进入下一层页面。可现实是，大多数黑盒扫描器并不理解这些流程，它们更多还是依赖BFS或随机点击的方式在页面之间游走，很难按照正确顺序完整走完一套操作。

这篇论文想解决的核心问题，用一句话概括就是：扫描器能不能像人一样，先理解“我要完成什么事”，而不是只盯着“当前页面能点什么”，作者注意到，大语言模型在训练过程中已经接触过大量Web应用的使用文档和操作说明，本身就具备对常见功能和典型流程的语义认知。基于这一点，论文提出了一种新的思路：不再把扫描器当作单纯的页面爬虫，而是将其视为一个以任务为目标的智能体，由LLM来判断下一步该做什么，从而带着扫描器进入那些传统工具几乎触达不到的深层页面。

二、具体方案研究

围绕“让扫描器能够理解并执行Web应用中的任务”这一目标，论文提出并实现了一个名为YURASCANNER的任务驱动式Web漏洞扫描系统。从整体设计来看，作者并没有重新发明漏洞扫描本身，而是把重点放在了如何更聪明地走到那些传统扫描器走不到的位置。从架构到实现，YURASCANNER的设计思路可以概括为：以任务为核心，用大语言模型指导扫描器的导航行为。

2.1 整体架构：任务驱动的扫描流程

从整体流程上看，YURASCANNER的工作可以分为三个阶段：任务生成（Task Extraction）、任务执行（Task Execution）和漏洞检测（Vulnerability Scanning）。

在任务生成阶段，系统从Web应用的入口页面出发，对页面中的菜单、按钮和链接等可交互元素进行分析，并借助大语言模型自动生成一组可能的任务描述；在任务执行阶段，扫描器以任务为目标逐步执行操作，在完成任务的过程中不断进入更深层的页面状态；最后，在漏洞检测阶段，对任务执行过程中发现的URL和表单进行动态安全测试，从而挖掘潜在漏洞。

这一流程的关键变化在于，扫描器不再是“走到哪扫到哪”，而是围绕任务目标持续推进操作，直到无法继续或任务完成为止。这种任务驱动的方式，使扫描器更接近真实用户的操作路径，也为发现隐藏在复杂业务流程中的漏洞提供了可能。为便于理解，论文给出了YURASCANNER的整体工作流程示意，如图1所示。

图1 YURASCANNER的整体工作流程

2.2 将扫描器建模为目标导向的智能体

在具体实现上，作者将扫描器抽象为一个目标导向的智能体，这是整篇论文中最核心、也最具创新性的设计决策之一。与传统扫描器主要依赖固定遍历策略不同，YURASCANNER不再只是机械地遍历页面，而是围绕当前任务持续做出决策，判断下一步应该执行什么操作。

从整体结构来看，这个智能体由三个模块组成：Sensors（感知模块）、Bridge（决策模块）和Actuators（执行模块）。三者形成一个不断循环的工作流程：页面加载后，先由Sensors对页面进行感知和抽象，再由Bridge借助大语言模型做出决策，最后由 Actuators在真实浏览器中执行操作，并进入新的页面状态。

图2 任务驱动扫描器的智能体结构设计

从图2可以清楚地看到 YURASCANNER 各个模块之间的协作关系。下面将围绕Sensors、Bridge和Actuators三个模块，分别介绍其具体实现方式。

（1）Sensors：从页面内容到语义化表示

Sensors模块负责系统的感知部分，其核心目标是将复杂、多样的网页内容转化为大语言模型能够理解和处理的语义表示。为此，系统并不会直接使用完整的 DOM 结构，而是聚焦于页面中真实可交互的元素，并有意识地过滤掉不可见元素、装饰性内容以及缺乏明确语义的信息。

通过这一抽象过程，页面被压缩为一组结构清晰、语义明确的操作描述。这种表示方式不仅减少了无关信息对模型决策的干扰，也为后续模块提供了更加稳定、可控的输入基础。

（2）Bridge：基于大语言模型的决策模块

Bridge模块是整个系统的决策核心，负责在当前任务目标的约束下，判断下一步最合理的操作。它会综合当前页面的抽象表示、任务描述以及最近的操作历史，并将这些信息一并输入给大语言模型进行分析。

在设计上，作者对模型的输出形式进行了严格限制，使其只能在预定义的指令集合中进行选择。这种做法有效降低了模型决策的不确定性，也避免了大语言模型直接、不可控地操作浏览器，从而提升了系统整体的稳定性。

图3 LLM决策Prompt部分模板

从图3可以看出，作者并未让大语言模型自由控制浏览器，而是通过明确的输入格式和有限的指令集合，对模型行为进行了严格约束。这种设计在引入LLM能力的同时，也保证了系统整体的可控性。

（3）Actuators：将决策转化为真实操作

Actuators模块承担执行职责，负责将Bridge给出的高层决策转化为具体的浏览器操作。它直接与浏览器实例交互，按照既定逻辑完成点击、表单提交等操作，并在操作结束后推动页面状态发生变化。

通过将决策和执行两个环节明确分离，系统在保留大语言模型灵活性的同时，也确保了执行层面的可控性和一致性。当页面状态更新后，系统会再次进入下一轮感知与决策流程，从而持续推进任务执行。

2.3 表单处理与任务执行细节

在Web应用中，表单承担着大量核心业务操作，扫描器能否正确处理表单，往往直接影响其是否能够进入更深层的页面状态。相比简单的点击行为，表单交互涉及字段填写和页面状态变化，处理难度更高，也是传统扫描器容易受限的环节。

针对这一问题，YURASCANNER采用了分离式的设计思路，将是否需要提交某个表单与如何填写表单内容拆分为两个阶段处理。前者由任务驱动的决策逻辑负责，在当前任务上下文中判断是否以及提交哪个表单；后者则通过单独的 Prompt交由大语言模型生成，从而避免表单细节干扰整体导航决策。

图4 表单填写Prompt模板

从图4可以看出，作者对表单填写阶段设置了明确的输入和输出约束，使模型只需关注字段本身，而不必同时考虑任务推进或页面跳转逻辑。这种设计在降低决策复杂度的同时，也提升了表单填写过程的稳定性。

在执行阶段，系统会根据模型生成的字段值完成表单填写与提交，并根据页面是否进入预期状态决定是否继续推进当前任务；若提交未产生有效变化，则当前任务会被中止，扫描流程转而尝试下一个任务。

三、实验方法与性能评估

为了验证任务驱动扫描在实际场景中的有效性，论文对YURASCANNER进行了系统性的实验评估。实验不仅关注扫描器是否能够访问更多页面，还重点考察其在真实业务流程中的执行能力、攻击面覆盖深度以及漏洞发现效果，并与传统黑盒扫描器进行了对比分析。

3.1 实验设计与评估方法

在实验设计上，作者选取了多个具有真实业务逻辑的Web应用作为测试对象。这些应用包含多步操作流程和复杂的页面状态变化，能够较好地反映现实Web漏洞扫描所面临的挑战。所有扫描器均在相同的实验环境、时间限制和配置条件下运行，以保证不同方法之间的可比性。

在评估方法上，论文并未仅以页面数量作为衡量指标，而是从更贴近实际使用的角度出发，重点关注以下三个方面：

l一是扫描器是否能够生成并执行具有实际意义的任务；

l二是扫描过程中是否能够进入更深层的页面状态，从而覆盖更多关键URL和表单；

l三是在此基础上，是否能够发现真实且具有安全价值的漏洞。

3.2 任务执行能力评估

首先，作者评估了YURASCANNER在任务执行阶段的表现。在扫描初期，系统会基于页面信息自动生成一组高层次任务，实验统计了这些任务的有效性以及在后续执行过程中是否能够被成功或部分成功完成。在任务执行能力方面，论文对YURASCANNER自动生成的任务进行了分类统计，结果如表1所示。

表1 任务执行结果分类统计

整体来看，大多数自动生成的任务都与应用的真实功能相关，其中相当一部分任务能够被完整或部分执行。任务执行失败的情况主要集中在前置条件不足或业务流程依赖较强的场景中。

图5 任务执行结果统计

图5展示了不同任务执行结果的分布情况，可以直观看出任务驱动方式在执行层面是可行的，但在复杂业务逻辑下仍然存在一定限制。

3.3 攻击面覆盖情况分析

在攻击面覆盖方面，论文通过统计不同扫描器在相同实验条件下发现的URL和表单数量，对其覆盖能力进行了对比分析。相关统计结果基于多组实验对象汇总得出，具有一定代表性。

实验结果显示，YURASCANNER能够发现大量传统黑盒扫描器未能触达的输入点，尤其是在表单覆盖数量上的提升更为明显。需要注意的是，在URL总数量上，两者的差距并不始终显著，但YURASCANNER新发现的URL和表单往往位于需要多步操作才能访问的页面状态中。

图6 不同扫描策略下的表单覆盖率对比

从图6可以看出，任务驱动扫描在覆盖深度上的优势更加突出，体现为对真实业务操作入口的更高触达能力。

3.4 漏洞发现效果评估

在漏洞发现效果方面，作者进一步统计了不同扫描器在实验过程中发现的漏洞情况。相关漏洞的整体汇总结果在论文的表2中给出，其中包含多个此前未被自动化工具发现的真实漏洞。

表2 攻击面覆盖情况汇总

实验结果表明，YURASCANNER在漏洞发现数量上明显优于传统黑盒扫描器，且发现的漏洞大多位于需要完成特定任务后才能访问的页面中。这一结论并非孤立得出，而是与前文攻击面覆盖结果相一致：只有当扫描器能够稳定进入真实业务流程，隐藏在深层页面状态中的漏洞才有可能被触发和检测。

从这一结果可以看出，任务驱动扫描并非简单地扩大扫描范围，而是通过引导扫描器进入关键业务路径，提高了对高价值漏洞的发现能力。

3.5 实验结果小结

综合实验结果可以看出，YURASCANNER在任务执行、攻击面覆盖以及漏洞发现等多个维度上均优于传统黑盒扫描器。实验结果进一步表明，扫描器若能够围绕任务目标持续推进应用状态，而非仅依赖页面遍历策略，将更有可能进入真实业务流程，从而发现隐藏在深层页面中的高价值漏洞。

四、论文的局限、未来展望和适用场景

4.1 研究的不足与限制因素

整体来看，YURASCANNER展示了任务驱动扫描在复杂业务场景中的潜力，但这一方法仍然难以摆脱对页面状态和前置条件的依赖。当业务流程强依赖登录状态或特定业务对象时，任务执行仍然容易受阻。从本质上看，该方法更多是在复现典型用户操作路径，而非真正理解业务规则本身。

此外，大语言模型的决策稳定性仍然是影响效果的重要因素。即便通过受限指令集和结构化Prompt对模型行为进行了约束，在页面结构复杂或任务链较长的情况下，模型仍可能提前终止或偏离既定目标，这一问题在实验中的失败任务中已有体现。

从工程角度看，该方法在算力消耗、运行环境和系统复杂度方面的成本也明显高于传统黑盒扫描器，其实际应用价值需要结合具体场景谨慎评估。

4.2 未来研究方向与适用场景

关于这篇论文，更重要的或许不是它解决了多少问题，而是它为漏洞扫描提供了一种新的视角。实验结果表明，影响任务执行效果的关键往往并不在于决策策略本身，而在于前置状态是否充分。如果未来能够更系统地管理登录状态、业务对象和关键上下文，任务驱动扫描在复杂应用中的稳定性和覆盖深度仍有提升空间。

从实际使用角度来看，这类方法更适合作为现有扫描流程的补充工具，用于挖掘传统扫描器难以触达的复杂业务流程和深层页面。在后台管理系统、流程型应用等业务逻辑复杂的场景中，其优势更容易体现；而在结构简单、交互流程有限的应用中，引入该方法的投入产出比则需要谨慎权衡。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：玄枢战队-Arcane Hub QIU QIU《论文研读与思考|YURASCANNER：一种基于任务驱动的大语言模型Web漏洞扫描方法》