323个探测探针如何判定漏洞真实存在:深度解析Ars0n Framework v2自动分诊引擎

Ars0n Framework v2 是一款面向新手的 AI 原生漏洞赏金狩猎框架（AI Native Bug Bounty Hunting Framework）。它的核心亮点之一是自动分诊引擎：用 323 个探测探针与十余个漏洞分类器协同工作，通过"基线对比 + 唯一标记 + 隔离判定"自动区分真实漏洞与误报，让新手也能获得接近专业研究员的判定质量。

为什么漏洞赏金新手需要"自动分诊"

跑一遍扫描器后，你通常不会只得到 1 条结果，而是成百上千条告警。问题来了：

• 🔍 这条 XSS 告警是真回显，还是页面里本来就有的字符串？
• 🧩 这条 SQL 报错是真实注入，还是模板里固定输出的错误页？
• ⏱️ 手工逐条验证，时间根本不够用

在漏洞赏金平台提交报告，平台要的是可复现的证据，不是扫描器的猜测。Ars0n Framework v2 的分诊引擎（Triage Engine）就是为这个痛点设计的：它在 server/utils/triageRun.go 中被描述为——把 323 个已声明的探针和注册的漏洞分类器，变成一条条带证据的判定记录（triage_verdicts）。

323 个探测探针：每个探针都是一份"先声明后执行"的契约

引擎里的每个探针不是一个随手拼出的请求，而是一份完整的声明（ProbeSpec），在 server/utils/triage/registry.go 中定义：

声明内容	含义
逻辑载荷（Logical bytes）	这个探针要发送的原始字节，构建期即锁定
插入点（Points）	打到 Query、Header、Cookie 还是路径
编码方式（Encoders）	URL 编码、百分号编码等变体
探针档位（Tier）	reduced 廉价档 / full 完整档 / opt_in 需操作者显式开启
风险等级（Risk）	R0 只读无副作用，逐级升高到 R3 可能破坏性操作

这套"档位 + 风险"设计对新手非常友好：

• 默认只跑廉价、只读的探针，不会因为好奇多发了几个危险请求；
• R3 级别的探针每次运行都要操作者显式选择才会发送；
• 因风险被拒绝的探针会记录为 not_probed 并附上原因，而绝不会悄悄记成"安全"。

判定漏洞"真实存在"的三个核心机制

机制一：基线对比——先测量"没攻击时"的样子

引擎遵循一条铁律：基线（Baseline）是唯一被共享的观测，它就是对照组。见 server/utils/triageRun.go：

• 基线按"向量"（vector，即一个带参数的接口模板）校准一次，而不是按每个参数校准——因为同一向量的所有插入点共享同一份请求模板；
• 所有分类器的判定都是差分出来的：攻击后的响应相对基线"多出来的东西"，才是漏洞信号；
• 这直接消灭了一大类误报：页面里本来就存在的报错文案，在差分下会完全消失。

分诊的输入正是框架前期阶段积累的成果——Katana 爬取的 URL 与 Ffuf 发现的端点，见 server/utils/urlCrawlerRun.go。

机制二：唯一标记——谁"回显"了我，一目了然

判定 XSS 或注入类漏洞时最头疼的问题是：响应里出现了我的载荷，但它到底是我发的那个探针回显的，还是别的什么东西？

分诊引擎的解法是标记（Marker）机制，实现在 server/utils/triageMarker.go：

1. 每个探针发出前，由**运行器（而非分类器）**铸造一枚唯一标记：锚点 + 运行 ID + 序号 + 校验和；
2. 序号采用条纹分配——序号对模数取余恰好等于所属分类器编号，所以任何一枚标记都能纯靠算术归属到具体类别，不需要查表；
3. 其他分类器收到这枚标记时，在数学上就不可能匹配它——不是"它忽略了"，而是"它匹配不上"；
4. 搜索不是简单的子串查找：标记必须能在大小写折叠、HTML 实体编码、百分号编码、字段截断后仍然被识别。而且**"被截断"与"不存在"是两种不同的结论**——截断意味着字段吃掉了标记的一部分，此时不能下任何结论，该记录永远不会被渲染为"安全"。

机制三：隔离法则——绝不共用同一段载荷

如果两个漏洞分类器发送了字节完全相同的载荷，那么目标的一次封禁或报错就无法归因到任何一个类，操作者可能误读其中一个为"干净"。

因此引擎在构建期就运行隔离检查（CheckPayloadIsolation），扫描所有已注册分类器的探针并集；两个类别携带相同载荷字节时，构建直接失败。这个检查甚至会在每次运行启动前、连同操作者自定义的载荷一起再验一遍，见 server/utils/triageRun.go。

"不确定"永远不等于"安全"

分诊引擎的四条设计规则写在 server/utils/triageRun.go 的头部注释中，每一条都深刻影响判定结果的可信度：

1. 隔离（Isolation）：一个分类器只能拿到属于自己的响应分区，编译器层面就堵死了"偷看别家响应"的可能（相关防护见 server/triageclasses/classes.go）。
2. 不知道 ≠ 干净（Not knowing is not clean）：载荷未送达、基线不稳定、类未运行、运行被取消、向量未勾选——这五种"没测出来"各有独立状态和原因，没有一种是 clean。
3. 漏报才是最贵的错误：引擎拿不准时宁可多打一发探针并记录不确定性，也不跳过然后记录沉默。
4. 基线是唯一共享物：它是所有类别做差分的唯一对照组。

这些原则最终落成数据库层的硬约束，定义在 server/utils/triageSchema.go：

• 一条 clean 判定必须有对应探针记录（没有证据就不能说安全）；
• 一条 unknown 判定必须携带原因；
• 一条阳性判定必须指明证据来源；
• 后写入的 clean 不允许覆盖已有的 unknown——"丢失一个 clean 只需重新探测，丢失一个发现则丢掉这个漏洞"。

覆盖哪些漏洞类型？

十余个漏洞分类器全部集中在 server/triageclasses/ 目录，包括：

• SQL 注入：sql.go
• 反射型 XSS：xssreflected.go
• SSTI 服务端模板注入：ssti.go
• LFI 本地文件包含：lfi.go
• CMDi 命令注入：cmdi.go
• CORS 跨域配置：cors.go
• 以及 CRLF、HPP、RFI、NoSQL、反序列化、路径穿越、重定向、Host Header、ORM 泄漏等

扩展方式极其干净：新增一个漏洞类 = 往这个目录加一个文件 + 一个 init() 注册，运行器代码零改动——没有 switch 语句，也没有需要手工同步的类别清单。

快速上手：三步启动一次自动分诊

🚀 在界面上操作分诊非常简单：

1. 确认输入：先完成爬取与端点发现，让向量列表有内容（可参考 server/utils/metaDataUtils.go 管理的目标元数据）；
2. 勾选分类器：在 Configure 弹窗中启用你关心的漏洞类别、选择探针档位（廉价档/完整档），高风险探针按需单独开启（配置持久化逻辑见 server/utils/triageSettingsAPI.go）；
3. 点击 Investigate：引擎会后台派生插入点 → 校准基线 → 执行前置步骤（如获取 ViewState 等必需令牌，见 server/utils/triagePrelude.go）→ 按预算节奏发送探针 → 写入覆盖率与判定结果。

全程受速率与节奏预算约束（server/utils/paceBudget.go），单个探针 12 秒超时、每槽每类最多 12 轮，避免对目标造成压力，也避免一次运行失控。

判定结果怎么看？

运行结束后，每个"向量 × 插入点 × 漏洞类别"都会有一条记录：

状态	含义	新手解读
clean	测过，且有探针证据支撑	可以放心跳过
positive	命中漏洞，且指明证据来源与位置	重点复核，准备写报告
unknown	没测出来，附具体原因（未送达/基线不稳/被取消…）	不是安全，可换时段重测
not_probed	因风险等级或档位被拒发	想测需手动开启 opt-in

覆盖率表中"有覆盖行但没有判定"的组合则明确表示"这个类别在这里没有运行过"，与"运行过且干净"严格区分——报告永远不会把"没测"画成"没问题"。最终结果可以一键导出 CSV 归档，见 server/utils/export.go。

对新手意味着什么

对漏洞赏金新手而言，这套自动分诊引擎的价值在于：

• ✅ 省掉 90% 的误报排查：基线差分 + 唯一标记让"看起来像"的告警无法蒙混过关；
• ✅ 证据链天生完整：每条判定都绑定探针记录、来源与证据偏移，写报告时直接可用；
• ✅ 安全边界内运行：风险分级 + 速率预算，让你可以放心地对真实目标演练；
• ✅ 可学习性极强：引擎的四条规则本身就是一堂漏洞验证方法论课。

配合框架内置的"Help Me Learn"教学式引导，Ars0n Framework v2 让新人从第一天起，就用专业级的方式判定漏洞是否真实存在。🎯