AI 如何发现复杂漏洞：深入解析智能体式渗透测试与漏洞利用链

SQL 注入很容易发现：注入一个 payload，返回一个错误，扫描器就会将其标记出来。这就是模式匹配，而传统的应用安全工具在这方面已经做得很好，长达二十年。

业务逻辑漏洞则完全是另一回事。没有任何内容是畸形的，也没有任何 payload 会破坏什么。请求在语法上完美无缺，完全通过身份验证，而且完全“有效”——它只是做了业务方从未打算允许的事情，比如让普通用户使用仅限内部的折扣码，或者让已通过身份验证的攻击者只需将 URL 中的整数减一，就能拉取另一个租户的发票。这类问题没有特征签名，也没有任何正则表达式能匹配“这个工作流在业务上毫无道理”。要发现它，就必须理解意图——应用本来应该做什么——然后推理这种意图可以如何被颠覆。

这种推理上的鸿沟，正是智能体式 AI 开始弥合的地方，这也是为什么攻击性安全领域谈论 AI 的方式，已经从“更智能的扫描”转向了“像人类黑客一样行动的自主智能体”。本文将从技术层面剖析这一切究竟如何运作：智能体如何构建上下文、如何映射攻击路径、如何将各自无害的发现串联成一个严重级别的漏洞利用，以及这种方法目前仍会遇到哪些真实的局限。在理论之外，我们还将剖析 Ostorlab Agentic Deep Scan 的一个真实发现：正是这种推理，把一个已被标记为“已修复”的硬编码凭据，变成了对整个租户身份系统的完全接管。

什么是智能体式渗透测试？ 智能体式渗透测试是指利用自主 AI 智能体构建应用的上下文模型、映射多步骤攻击路径，并将看似低严重程度的发现串联成严重级别的漏洞利用，从而模拟人类安全研究人员的推理循环。

为什么基于规则的扫描器会遭遇天花板

SAST 和 DAST 工具建立在同一个基本原语之上：将输入或代码与已知的恶意模式进行匹配。这个原语速度快、结果确定，在 CI 流水线中运行成本低廉——但它存在三个结构性盲区，无论增加多少规则都无法完全弥补。

局限	产生原因	遗漏的内容
请求之间没有状态	扫描器通常孤立地、逐个请求地评估端点	多步骤滥用：添加商品、使用优惠券，然后在结账前将数量修改为负数
没有“应该”的概念	规则编码的是语法而非意图——语法上有效的请求无法被特征签名标记	普通用户调用一个从不检查角色的仅限管理员的导出端点，因为请求本身没有任何畸形之处
没有跨账户的授权上下文	单会话爬虫难以推理某个对象的数据属于谁	BOLA/IDOR——拥有对象 1041 的用户拿到了对象 1042，响应为 200 OK 和有效的 JSON

厂商们试图通过更多的规则、更多的正则表达式和更大的特征库来修补这些缺口，但底层架构依然是被动反应式的：当下匹配、当下处理，然后忘掉之前的十个请求。业务逻辑漏洞恰恰存在于这种架构看不到的缝隙中——跨越步骤、跨越账户，以及工作流“应该允许什么”与“实际允许什么”之间的差距。

这里的“智能体式”究竟是什么意思

智能体式渗透测试系统用一个循环取代了单一的“匹配并报告”步骤，这个循环更接近人类渗透测试人员的实际工作方式：

1. 侦察——枚举攻击面：端点、参数、身份验证流程、角色、隐藏或未文档化的 API 路由。
2. 假设——根据观察到的行为推理可能出现什么问题（“这个端点接受一个 order_id，却从不检查所有权——值得作为 BOLA 候选进行测试”）。
3. 测试——构造并发送一个能够证明或推翻该假设的请求，并根据响应进行调整。
4. 验证——确认该发现确实可被利用而不是误报，通常是通过复现真实影响来确认。
5. 串联——思考这个发现与已经发现的任何内容结合后，是否能打开一条智能体尚未尝试过的路径。

第 2 步和第 5 步才是关键区别。 基于规则的扫描器具备第 3 步，以及较弱的第 4 步。它不会对意图形成假设，也没有对先前发现的记忆，无法将其与当前发现结合起来。相比之下，由 LLM 驱动的智能体会持续维护一个应用模型——它学到了什么、怀疑什么、已经排除了什么——并利用这个模型决定下一步尝试什么，就像人类测试人员在为期多天的项目中持续记录心得一样。

在发起任何攻击之前先建立上下文感知

在智能体能够发现任何有价值的东西之前，它需要建立一个远超 URL 列表的应用工作模型。在实践中，这一上下文构建阶段通常涵盖：

• 授权模型——存在哪些角色、每个角色应该能做什么，以及这些规则如何被执行（JWT 声明、会话状态、RBAC 中间件，或者——正如下文案例研究所示——某个 OAuth 客户端实际注册了哪些受众（audience）和作用域（scope））。
• API 与 Schema 结构——OpenAPI/Swagger 规范、GraphQL 自省，或者在具备代码感知能力的环境中，直接从代码仓库中提取的实际路由和控制器逻辑。
• 多步骤工作流——结账流程、用户引导、密码重置、邀请/审批链——通过像用户一样真正走一遍应用来重建，而不只是列出端点。
• 代码级可达性——在具备代码感知能力的智能体中，这意味着从入口点（HTTP 路由、消息队列消费者）出发遍历调用图，查看受污染的输入是否真的能够到达敏感的汇聚点（sink），而不是按名称标记每一个有风险的函数调用。

这与一名合格的人类渗透测试人员在项目侦察和映射阶段所做的基础工作相同——阅读文档、以不同角色点击浏览应用、记录哪些地方应该存在权限边界——不同之处在于，智能体可以同时在工作记忆中保存整个 Schema、每个角色允许的操作以及之前的每一个测试结果，并在每次新发现改变全局时重新检查所有这些内容。

从单个发现到攻击路径

一旦智能体拥有了应用模型，它就不再把每个端点视为孤立的测试目标，而是开始把整个应用视为一张图：入口点、信任边界，以及连接它们的边。这更接近攻击路径映射，而非扫描——问题从“这个端点是否存在漏洞？”转变为“基于目前发现的一切，从一个未经身份验证的请求到达真正重要的东西——管理员权限、另一个租户的数据、资金流转——最短路径是什么？”

正是这种图视角让串联成为可能。一个孤立来看像是死胡同的发现——比如一个没有直接影响的信息泄露——可能恰恰是那条缺失的边，把另外两个发现连接成一条通向完全沦陷的可行路径。基于规则的扫描器没有图，它只有一份相互独立的告警列表。而智能体拥有一张不断更新的图。

核心能力：将低严重程度的发现串联成严重级别的漏洞利用

这是智能体式测试与传统扫描之间最大的区别所在，因此在看真实案例之前，值得先完整走一遍一个贴近现实的示例。

场景：一个多租户的 B2B SaaS 平台，带有标准的开票功能。

发现 1（低危——信息级）： 应用在 /api/v1/users/{id}/profile 上的错误响应泄露了用户 ID 是连续整数这一事实，而且对于超出范围的 ID，该端点返回的是通用的“未找到”，而不是正确的 403——从技术上讲严重程度较低，因为返回的个人资料数据很少，但它证实了 ID 空间是可枚举的。

发现 2（中危——BOLA）： /api/v1/invoices/{id} 执行了身份验证但没有执行授权——它检查是否存在有效会话，却从不检查发起请求的用户所在的租户是否拥有被请求的发票。单独来看，团队通常会将其分级为“中危”，因为发票中不包含凭据。

发现 3（低危——设计缺陷）： 生成的发票 PDF 中嵌入了一个“管理您的订阅”深度链接，其中包含一个有效期为 24 小时的密码重置令牌，而该令牌是由可预测的种子（时间戳 + 用户 ID）生成的，而非密码学安全的随机值——之所以被标记为低危，是因为单独利用它需要事先知道特定用户的 ID 和创建时间戳。

单独来看：三张工单，没有一张高于中危，很可能被排进几个月后的某个常规迭代。

串联起来：一个已经通过发现 1 掌握了 ID 枚举方式的智能体，利用它针对发现 2 遍历发票 ID，跨租户拉取发票，直到找到一张属于管理员账户的发票。这张发票 PDF 中包含发现 3 中的深度链接。由于令牌的生成种子现在可以推导出来（智能体从发票元数据中拿到了用户 ID，并从开票日期得到了时间戳的范围），它重建出一个有效的重置令牌，重置了管理员的密码，并以完整的租户管理员权限登录——这就是跨租户账户接管，而它来源于三个在任何单独扫描结果中都不会被标记为紧急的发现。

这就是“漏洞利用链”在实践中的含义：不是某个巧妙的 payload，而是在已发现的攻击面上进行的图搜索，智能体在其中不断追问“我发现的其他东西是否会让这个问题变得可被利用？”基于规则的扫描器会产出三张独立的低危/中危工单，然后就此止步。而一个在整个项目中维护状态的智能体能够识别出其中的关联，因为它从未停止把应用当作一个整体系统来建模。

亲眼见证：Agentic Deep Scan 发现的一条真实漏洞利用链

上面的开票场景只是示例。它所描述的模式——一个发现看似范围有限，直到它与智能体已知的其他一切放在一起测试——在真实项目中屡见不鲜。下面就是一个例子，来自 Ostorlab Agentic Deep Scan 针对一款 iOS 应用的一次扫描（以下数值均已脱敏或使用虚构域名 acme.test，与底层租户在测试中的范围界定方式保持一致）。

发现 #1——评级为高危，随后被标记为已修复且已验证： “硬编码的 Auth0 M2M OAuth 凭据可为内部 ACME 服务签发生产环境 JWT”。引擎拆解了应用的 Mach-O 二进制文件，发现了一组有效的 Auth0 机器对机器 client_id 和 client_secret，它们是在构建时通过 Flutter 的 DART_DEFINES 机制嵌入的——这是将后端配置注入移动构建版本的常见模式，也是不小心把后端密钥分发到每一台安装该应用的设备上的常见途径。

图 1：最初的发现。被提取出的凭据已被证明是有效的——而不只是存在于二进制文件中：向该租户的 /oauth/token 端点请求令牌，确认返回 HTTP 200 和一个真实签名的 JWT，并与使用伪造凭据时返回 HTTP 401 的基线进行对照。

对返回的 JWT 进行解码后，确认该令牌是真实的，并且与这个特定租户绑定：一个 read:TSC 作用域、一个客户端凭据授权类型，以及一个可追溯到该租户自身 JWKS 端点的签名密钥——而这个 JWKS 端点恰好还泄露了内部租户的主机名。

图 2：此时，这个发现看起来范围有限。该令牌只针对一个受众声明了 read:TSC，该发现已被分级处理、修复，并以高危级别完成验证——这是一个真实的凭据管理问题，但影响范围是有界的。

扫描器——坦率地说，还有大多数一次性的人工审查——到这里就会止步。凭据被确认有效，风险已被记录，工程团队轮换凭据或缩小其权限范围，工单随之关闭。但智能体没有止步，因为“已修复且已验证”回答的是该凭据是否有效，而不是该凭据能够通过身份验证访问的所有内容。

发现 #2——评级为严重，仍处于未解决状态： “ACME iOS 应用中硬编码的 Auth0 M2M 凭据可访问 Auth0 Management API，并导致整个租户的用户个人身份信息（PII）外泄”。同一组嵌入的凭据仍然有效。智能体的下一个假设很简单，与上文描述的“假设”步骤一脉相承：一个 Auth0 M2M 客户端可以被授权访问不止一个受众，而应用只会使用它被构建来调用的那一个——那么，这个客户端实际上还注册了哪些受众？

图 3：与发现 #1 相同的 client_id 和 client_secret。受众枚举显示，它们还注册了 Auth0 Management API 受众，该受众签发的令牌带有 8 个不同的作用域——包括 update:users、delete:users、create:users 和 create:client_credentials。

漏洞利用证据清楚地展示了这一横向突破是如何被发现和验证的：靠的是系统性的受众枚举，而不是侥幸猜中。

图 4：第 1 步针对发现 #1 中使用的同一个令牌端点测试了 38 个候选受众，直到该租户自身的 Management API，即 https://acme.auth0.test/api/v2/ 返回了 HTTP 200 而不是 403。第 2 步使用得到的令牌发出了一次非破坏性的 GET 请求，取回了包含 1,000 条记录的完整用户目录：电子邮件、电话号码、最近的 IP 以及登录行为。

把两个发现放在一起对比，串联的逻辑与上一节中的图搜索思路完全一致，只是这里的图换成了凭据的授权面，而不是一组端点：

	发现 #1（已修复）	发现 #2（未解决）
相同的根本原因	硬编码在 iOS 二进制文件中的 M2M 凭据	相同的凭据，相同的二进制文件
测试了什么	应用自身调用的那一个受众	系统性地测试了 38 个候选受众
解锁了什么	一个针对内部服务的 read:TSC 令牌	一个带有 8 个作用域的 Management API 令牌
实际影响	有界的内部服务访问	完整的租户用户目录（1,000 条 PII 记录），以及创建、更新和删除用户、签发新客户端凭据的潜在能力
重新测试时的状态	已经是“已修复且已验证”	仍未解决——修复针对的是已知的受众，而不是该凭据实际的授权面

发现 #2 并不需要新的漏洞类别或巧妙的 payload。它需要的是把“这个凭据对受众 A 有效”当作一个需要继续测试的假设，而不是一个已经结案的问题——正是同样的直觉，在上面的示例演练中把三张互不相关的低危/中危工单变成了一次租户接管。这里的不同之处在于，它所依托的那个发现早已被标记为已解决，而这正是状态和重新评估之所以重要的原因：一个关闭了已记录路径的修复，仍然可能让底层凭据的全部影响范围处于未被映射的状态。

最能体现价值的地方：业务逻辑漏洞

业务逻辑漏洞正是这种具备上下文、维护状态的方法最能体现价值的类别，恰恰因为这些漏洞并不对应某个 CWE 特征——它们对应的是关于工作流应如何运作的某个被打破的假设。

业务逻辑漏洞	基于规则的扫描器看到的	智能体测试的内容
结账价格篡改	POST 请求体中的一个价格参数——没有任何畸形之处	服务器是否在服务端重新校验价格，还是在最终扣款时信任客户端提交的值
优惠券/折扣叠加	两个有效且各自独立正常工作的 API 调用	先使用优惠券 A 再使用优惠券 B，是否会绕过前端强制执行而后端没有执行的“每单仅限一个折扣”规则
负数数量/退款滥用	一个接受整数的数量字段	负数数量是否会被接受并作为抵扣处理，而不是被拒绝
跳过工作流步骤	相互独立、各自经过身份验证的端点调用	在不经过第 1–2 步的情况下直接调用 4 步审批工作流中的第 3 步，是否仍能完成该操作
有限资源上的竞态条件	不适用——对单请求扫描器来说，时序是不可见的	针对有速率限制或一次性使用的端点（促销码、提现）发起并发请求，查看“先检查后执行”的逻辑能否被竞争利用

这些都不需要不寻常的 payload。它们需要的是一个理解工作流用途的智能体，然后系统性地尝试设计者没有预料到的操作顺序、参数值和时间窗口——这正是熟练的人类测试人员在不再寻找语法错误、转而开始追问“如果我打乱顺序会发生什么？”时所做的探索。

解决误报问题：靠证据，而不是模式匹配

上下文感知解决了一半的问题，另一半是信任。安全团队多年来一直在学着忽略扫描器的噪声，如果工程团队不相信输出结果，那么一个通过“推理”得出发现的智能体就毫无价值。成熟的智能体式平台最终殊途同归的解决办法，与漏洞赏金分诊人员会采用的办法相同：不报告假设，只报告证据。

在实践中，这意味着验证步骤（上述循环中的第 4 步）并不是一个置信度分数——而是一次真实的复现，与上文图 1 和图 4 所展示的内容相近：一个可运行的请求、它产生的确切响应，以及该响应所证实的具体结论。这意味着：

• 生成可运行的概念验证，通常是一条可执行的 cURL 命令或请求脚本，开发人员运行它即可亲眼看到漏洞利用的发生。
• 捕获完整的证据链——请求、响应，以及在相关情况下展示真实影响的截图或日志（屏幕上出现另一个租户的数据、权限变更生效）。
• 在修复上线后重新测试该发现，以确认补丁确实关闭了这条路径，而不只是改变了错误信息——这正是能够更早发现上文发现 #2 的那种检查，因为发现 #1 的修复并没有消除该凭据更广泛的授权面。

这也是为什么即使在高度自主的流水线中，人在回路（human-in-the-loop）的审查仍然有其一席之地：新颖的发现，或涉及特别敏感系统的漏洞利用链，在进入开发人员的待办队列之前，最好由人来确认智能体给出的证据。目标并不是把判断从流程中移除——而是确保所做出的判断，无论来自人还是自动化系统，都有证据支撑，而不是基于模式匹配。

这些系统实际上是如何构建的

在底层，智能体式渗透测试平台通常会收敛到一种分层架构，而不是由一个单体模型同时包揽一切：

• 一个协调层，负责界定目标范围、将项目拆分为相互独立的工作流，并决定将每个工作流交给哪个专业智能体——它本身不发起任何攻击。
• 专业智能体，每个专注于一个更窄的问题：一个专门用于 BOLA/IDOR 探索，一个用于身份验证和会话漏洞，一个专门用于多步骤业务逻辑滥用，一个用于对之前已修复的问题进行回归测试。
• 沙箱化的确定性工具，供智能体调用以完成实际的机械性工作——发送请求、解析响应、比对状态差异——这样 LLM 推理的是该测试什么，而不是每次都从零开始手工构造原始 HTTP 流量。

以这种方式拆分架构，对准确性和安全性同样重要：一个试图同时推理侦察、注入、访问控制和业务逻辑的通用智能体，往往会在拥挤的上下文窗口中迷失方向。更专注、相互协调的智能体能够保持聚焦，这也是为什么每个智能体背后具体使用哪个模型，往往不如编排层管理范围、记忆和工具访问的能力重要。专为应用安全打造的平台——Ostorlab 的 Agentic Deep Scan 就是其中之一——在 Web 和移动目标上都采用了同样的模式，将自主探索与一个在呈现每个发现之前都会重新验证的 AI 分诊层相结合，因此开发人员看到的输出是有实证支撑的发现，而不是模型的原始猜测。

人类仍然占优的地方

这一切都不会让人类渗透测试人员变得多余，这个领域中更可信的厂商对此也明确表态。智能体式系统目前最擅长的是那些奖励系统性、穷尽式探索的漏洞类别——基于角色的访问控制、跨大量对象和租户的 IDOR/BOLA，以及以人类在相同时间内无法企及的规模应用已知的串联模式（逐一测试 38 个候选受众正是这类任务）。相比之下，它们在以下方面较弱：需要跳出已接触过的模式、进行创造性横向思维的真正新颖的攻击链；深度的业务风险判断（“这在技术上可被利用，但对这个特定客户来说在运营上是否无关紧要？”）；以及完全不在 API 攻击面范围内的社会工程或涉及物理层面的场景。

2026 年的现实图景是增强而非替代：智能体负责持续的、广覆盖的探索，这些工作过去会占用渗透测试项目的大部分日程时间；而人类测试人员则把时间花在更难、更具创造性的那 10% 的发现上——同时验证智能体产出的结果。

评估智能体式 AI 渗透测试平台：真正需要检查什么

对于正在决定是否将这类工具引入 DevSecOps 流水线的应用安全架构师来说，以下几个问题可以穿透大部分营销话术：

• 它是在整个项目中维护状态，还是针对每个端点重复运行孤立的测试？状态是能够进行串联的前提。
• 每个发现是否都附带可复现的证据（一个可运行的请求，而不只是一段描述），而不是一个需要您手动验证的严重程度评分？
• 它能否测试经过身份验证的多角色工作流——以多种不同的用户类型登录并测试跨角色访问，而不只是扫描未经身份验证的攻击面？
• 它是否会在修复后重新测试，从而形成闭环，而不是让您的团队手动确认修复——包括检查修复是否覆盖了完整的授权面，而不只是最初报告的那条特定路径？
• 它如何融入 CI/CD——能否在每个拉取请求上运行而不成为瓶颈，是否能与开发人员已经在使用的工单系统集成？
• 人在回路的模式是怎样的——高影响或新颖的发现在到达工程团队之前是否有审查步骤？如果数据驻留对您的组织很重要，能否使用您自己的模型/API 密钥？

常见问题

AI 智能体能发现业务逻辑漏洞吗？ 能，但有其限度。能够维护角色、工作流和先前发现等上下文的智能体，可以识别结账篡改、跳过工作流步骤以及跨租户访问等逻辑漏洞，而基于模式的扫描器在结构上无法检测这些问题，因为这些漏洞并不对应畸形的请求。对于需要针对特定组织独有的业务风险进行判断的漏洞，它们的可靠性较低。

智能体式 AI 渗透测试与传统 DAST/SAST 有何不同？ DAST 和 SAST 逐个请求地将请求或代码与已知的恶意模式进行匹配，在整个项目中几乎没有记忆。智能体式渗透测试则运行一个持续的推理循环——侦察、假设、测试、验证、串联——它维护着整个应用的工作模型，并主动寻找先前的发现如何组合成更大规模的漏洞利用。

从技术上讲，自动化漏洞利用链工具是什么？ 它们是把已发现的攻击面当作一张图而不是一份列表来处理的系统，会跟踪每个发现如何改变应用中其他位置的可达性。当一个新发现被确认时，智能体会重新评估它是否与已经发现的任何内容相关联——就像一个信息泄露可能让一个之前被评为“中危”的 IDOR 能够被大规模利用，或者一个暴露凭据的完整授权面可能远远超出它最初被报告时所针对的那个受众。

智能体式 AI 渗透测试工具能消除误报吗？ 没有任何工具能完全消除误报，但领先的平台通过在报告发现之前要求提供可利用性证据——可运行的 PoC 和证据链——来显著减少误报，而不是报告模式匹配结果或模型的置信度分数。

AI 能取代人类渗透测试人员吗？ 目前还不能，大多数可信的厂商也没有这样宣称。智能体擅长针对已知漏洞类别进行系统性、广覆盖的测试，其速度和规模是人类无法企及的。而人类在新颖的攻击链、业务风险判断，以及在影响最大的发现到达客户或工程团队之前对其进行验证等方面，仍然更胜一筹。

结论

基于规则的扫描器会继续捕获那些在网络传输层面看起来就有问题的漏洞。而那些看起来没问题的漏洞——隐藏在工作流假设中的漏洞，或者隐藏在一个完整授权面从未被彻底映射的凭据中的漏洞——需要一种像攻击者那样推理的能力：构建系统模型、形成假设、进行测试，并不断追问它还与什么相关联。这正是智能体式 AI 在应用安全领域所代表的真正技术转变，也是为什么应用安全领域的讨论已经从“我们能否扫描得更快”转向了“我们能否像攻击者一样思考，持续不断地，并且达到现代应用资产的规模”。