LLM驱动Web逻辑漏洞自主测试实践

  //  

在Web安全测试中，业务逻辑漏洞始终是自动化最难跨越的盲区。传统工具能够快速枚举接口、变异参数，却无法判断一次合法请求是否违背了角色、资源、状态和业务时序。安全人员仍需投入大量精力梳理流程、构造前置状态并排除误报。

解决这一困境，关键不是继续扩充Payload，而是让系统先理解业务，再验证风险。我们通过真实浏览器测绘业务功能，以知识图谱保存页面、接口、权限和状态关系，再以Function为锚点开展威胁建模和Agent自主验证，使隐性的业务规则转化为可分析、可推演、可复核的测试目标。

本文将围绕传统方案为何失效，以及这套体系如何完成自主验证展开。

1

业务逻辑漏洞面前，传统自动化测试为什么失效？

面对业务逻辑漏洞，传统自动化测试的问题不是“扫得不够多”，而是它采用的检测模型从一开始就没有面向业务规则。

传统扫描器的工作方式建立在几个默认前提上：漏洞通常具有可复用的攻击特征，可以通过单次或少量请求触发，响应中存在可识别的异常信号，而且接口在脱离复杂业务上下文后仍然可以被独立判断。对SQL注入、XSS、路径穿越等技术型漏洞而言，这些前提大多成立，因此规则库、Payload库和响应匹配能够持续发挥作用。

业务逻辑漏洞却恰好打破了这些前提。

第一、业务逻辑漏洞通常没有稳定、通用的Payload。

攻击者发送的往往是语法正确、协议合规、类型合法的普通业务参数。price=0.01、quantity=-1、status=completed本身不是漏洞特征，只有结合商品原价、数量约束、订单状态和当前操作阶段，才能判断这些值是否破坏了业务规则。

第二、单个请求并不能表达完整的业务风险。

逻辑漏洞往往依赖身份、资源和状态之间的组合关系。GET /orders/10001既可能是用户查看自己的订单，也可能是普通用户读取其他人的订单。请求格式完全相同，区别只存在于“当前会话是谁”和“订单属于谁”这两个业务事实之间。

同样，订单接口返回成功并不一定意味着存在漏洞。只有先确认订单是否支付、是否属于当前账号、是否已经进入允许修改的状态，才能判断这次成功是否合理。脱离这些上下文，传统自动化工具只能看到HTTP请求和响应，无法看到请求背后的业务关系。

第三、逻辑漏洞缺少稳定的判断依据，也就是缺少自动化测试所依赖的“预言机”。

传统漏洞可以通过报错、回显、时间差或特征字符串判断测试是否成功；逻辑漏洞的响应却经常是正常的200状态码和“操作成功”。真正异常的不是响应内容，而是系统允许了一次本不应该被允许的操作。

第四、逻辑漏洞具有明显的状态性和链路性。

漏洞可能并不存在于某一个接口，而是来自多个合法步骤的错误组合。正常流程要求“创建订单—完成支付—确认发货”，攻击流程却可能跳过支付，直接调用发货接口；也可能先从一个接口获取资源ID，再借助另一个接口完成越权操作。

因此，针对业务逻辑漏洞，传统方案的瓶颈不是规则库规模不足，也不是Payload生成速度不够，而是缺少对业务语义、角色关系和状态约束的理解。工具认为该测的请求都测了，安全专家却仍然需要重新梳理业务、构造前置状态、切换账号并手工判断结果。

2

从业务理解到自主验证：LLM驱动的逻辑漏洞测试体系

大语言模型为打破这一僵局提供了新的可能。

它的价值并不只是“会写Payload”，而是能够阅读上下文、理解字段语义、分析角色关系、推演状态变化，并根据实际响应调整后续行动。当这种语义推理能力与真实浏览器、HTTP请求、知识图谱和任务编排系统结合后，逻辑漏洞测试便可以从“流量驱动”转向“语义驱动”。

整个体系遵循一个基本原则：先理解业务功能，再进行漏洞测试。

 2.1

先理解业务：

从真实浏览器探索到业务知识图谱

系统首先通过控制真实浏览器访问目标站点，执行点击、填表、导航和登录等操作。与仅抓取URL的传统爬虫不同，这一过程关注的不只是页面能否到达，还会同步记录页面变化、用户操作以及浏览器产生的网络请求。

当系统进入商品详情页并点击购买按钮时，它需要识别这不是一次孤立的页面跳转，而是“查看商品”“创建订单”等业务功能的组成部分；当浏览器发起一个POST请求时，系统不仅记录接口地址，还要理解请求参数、响应内容以及该接口与当前业务操作之间的关系。

这些信息最终被组织成一张业务知识图谱。

图谱中包含Site、Page、Function、Component、Api、ApiField、Request、Response、Session和Resource等实体，并使用页面跳转、接口调用、参数关联、请求响应以及角色权限等关系将它们连接起来。

页面不再只是一个URL，而是业务功能和交互组件的载体；接口不再只是一个请求地址，而是与页面、功能、参数及请求响应样本相互关联的业务能力；Session也不只是Cookie，而代表某个角色在特定状态下能够看到哪些页面、调用哪些接口、执行哪些功能。

知识图谱还解决了传统存储方式难以处理的多跳关联问题。

当验证一个订单功能时，系统可能需要同时找到它关联的页面、调用的API、接口中的字段、已有请求样本、不同角色的访问权限，以及与支付或退款有关的其他功能。如果这些信息分散在日志和文件中，模型需要反复读取和拼接；而在图谱中，相关信息可以沿着实体关系快速检索。

  2.2

锚定业务功能：

Function级威胁建模与自主验证

在完成业务结构与接口知识沉淀后，系统进入真正的逻辑漏洞检测阶段。

这里选择Function作为基本检测粒度。

如果以页面为单位，范围往往过于宽泛；如果以接口为单位，又容易失去业务上下文。Function位于两者之间，可以同时关联所在页面、交互组件、调用接口、参数字段、请求响应样本以及不同角色的访问权限。

以“修改收货地址”为例，它可能涉及地址列表页面、编辑组件、查询接口、更新接口、用户身份和地址资源。只有将这些信息组织在同一个功能上下文中，系统才有条件判断：当前账号能否修改其他用户的地址？资源ID是否与会话身份绑定？更新接口是否绕过了页面中的校验？

系统会针对每个Function进行数据流分析，梳理外部实体、处理过程、数据存储、数据流和信任边界，并结合STRIDE方法审视身份伪造、参数篡改、信息泄露、拒绝服务、抵赖和越权提权等风险。

威胁分析结果不是泛泛而谈的安全建议，而是一组结构化Risk。每条Risk都包含风险名称、业务影响和建议验证方法，随后被转换为独立验证任务。

验证Agent接到Risk后，首先制定测试计划，然后根据需要调用HTTP请求、真实浏览器、登录与认证状态恢复、验证码识别、知识图谱检索以及沙箱执行等工具。

2.3  

获得全局视角：

图检索、记忆与证据闭环

局部上下文并不足以支撑所有风险判断。

一个Function通常只包含当前功能的直接信息，而真实攻击链可能跨越登录、用户中心、订单、支付等多个功能。为此，验证Agent可以通过图检索能力查询全站知识图谱。

它可以询问“哪些接口使用了userId字段”“哪些页面调用了当前订单接口”“不同Session可以访问哪些功能”“哪个接口的响应中包含目标资源ID”。图检索会将自然语言问题转换为受限查询，再把相关实体、关系和请求样本整理为可消费的答案。

图谱提供空间上的全局视角，记忆机制则提供时间上的经验复用。

在验证过程中发现的账号、Token、登录方式、验证码机制、权限规则和关键业务参数，会被沉淀为全局记忆或Function级记忆。后续Risk开始前会读取最新信息，从而复用前序测试已经确认的认证状态和业务认知。

从整体上看，这套体系形成了完整闭环：

逻辑漏洞测试由此不再围绕孤立流量进行猜测，而是沿着真实业务结构“按图索骥”。

3

实战案例：通过篡改订单ID水平越权

下面以电商系统中的“为订单添加优惠券”功能为例，展示系统如何验证一类典型的水平越权风险。业务规则要求普通用户只能对自己的订单使用优惠券，但目标接口直接接收订单标识；如果服务端没有将订单归属与当前会话绑定，攻击者就可能通过替换订单ID操作其他用户的订单。

3.1

风险建模：

从Function上下文提出越权假设

站点测绘阶段已经记录了优惠券页面、订单接口、订单标识字段以及不同用户会话之间的关联。风险建模Agent以“添加优惠券”Function为锚点梳理数据流，并通过STRIDE威胁建模方法识别出水平越权风险。

这里的验证目标不是观察订单ID被替换后接口是否返回200，而是回答一个业务问题：普通用户A能否在保持自身登录身份的情况下，使优惠券作用于属于用户B的订单。这个判断同时依赖当前身份、资源归属和操作后的订单状态，无法由单个响应码完成。

3.2  

自主验证：

规划任务并执行身份对照

风险进入验证阶段后，风险验证Agent会根据功能点和风险点的详细信息定制测试用例，并根据测试过程动态调整。整个过程围绕同一风险持续推进，而不是对接口执行一次孤立的参数变异。

对于这个案例，风险验证Agent执行了如下验证操作：

第一步，Agent使用用户A的会话对其自有订单执行一次正常的优惠券操作，记录请求参数、响应内容和订单状态，建立基线。

第二步，Agent通过用户B会话或图检索获得一笔属于用户B的有效订单标识，同时保留用户A的认证状态，确保后续请求仍由用户A发起。

第三步，Agent在用户A会话下重新进入优惠券流程，将目标订单ID替换为用户B的订单ID并提交请求；除了资源标识外，其余参数与正常业务请求保持一致。

第四步，Agent重新查询用户B订单，或切换到用户B会话检查订单详情，确认优惠券状态、优惠金额或应付金额是否发生变化。只有目标资源出现可重复的状态变化，才进入漏洞结论。

3.3  

结果判定：

用业务状态变化建立证据链

本次示例中，用户A提交篡改后的订单ID后，接口返回操作成功；再次查看用户B订单，可以观察到优惠券已被应用，订单优惠状态和应付金额随之变化。服务端虽然验证了登录状态，却没有验证目标订单是否属于当前用户。

系统据此判定存在水平越权漏洞。证据链由三部分组成：请求由用户A的有效会话发起，目标订单明确归属于用户B，操作前后的用户B订单状态发生一致且可复现的变化。由于漏洞能够跨账户影响他人订单优惠和金额，按高风险处理。

这一案例体现了智能化逻辑漏洞测试的四项关键能力：从图谱中获取真实订单标识，而非依赖固定Payload；维护用户A和用户B的独立会话与资源归属；根据响应反馈完成多步骤验证；通过业务状态变化而不是单一响应特征形成结论。

AI-PTS 2.0，让逻辑漏洞挖掘走向自主验证

2026年7月15日，绿盟科技正式发布新一代智能渗透测试系统AI-PTS 2.0。系统围绕任务规划、Web资产测绘、漏洞分析、攻击验证和报告生成等关键环节，构建端到端自主化渗透测试闭环。

AI-PTS 2.0的价值并不是简单地把大模型接入扫描器，而是把业务理解、全局关联、长程推理和工具执行组织成稳定的工程闭环。在明确授权和安全边界下，系统能够持续探索目标、形成业务认知、提出风险假设，并通过真实操作验证结论。

从“看到接口”到“理解功能”，从“生成Payload”到“推演业务规则”，再从“发现异常”到“自主验证”，AI-PTS 2.0正在推动逻辑漏洞挖掘由高度依赖专家手工经验，走向可规模化、可追溯的智能化实践。