4.3 BChecks自定义检测

4.3 BChecks自定义检测

本节摘要：BChecks 是扫描器的声明式扩展机制：用结构化描述文件表达"什么信号组合构成一个可疑结论"，不用写代码就能给扫描器加自定义检查。本节讲它的适用位置、一份可用的定义结构，以及把团队检测经验沉淀成规则的完整过程。

用声明式规则表达检测意图

上一节的处置流程里留了个念想：同一类上下文型条目反复人肉确认，能不能让机器先按业务口径筛一遍。扩展模块是一种答案，但写代码的门槛把多数团队挡在外面。BChecks 是更轻的答案——它是一份人类可读的描述文件，机器负责执行。你声明三件事：对什么信号做匹配（请求侧或响应侧）、信号之间什么逻辑关系（与、或）、命中后产出什么级别的问题条目。声明完了，扫描器在审计阶段自动执行它。

它有清晰的适用边界。单次请求或简单多步请求能表达的检测逻辑，适合写成 BChecks；需要复杂状态管理、动态计算签名、跨请求复杂关联的逻辑，老老实实用扩展模块写代码。经验法则：能用"看到 A 且看到 B 就报 C"说清的检查，先试 BChecks。

一份定义的解剖

下面是一个教学用例子：靶场留言板的昵称参数若把特定标记反射进响应，且响应头缺少内容安全策略，则产出一条低危提示。为聚焦结构做了简化，字段以你所用版本的内置模板为准。

definition:
  name: Lab reflection and header check
  description: 教学示例：标记反射且缺少内容安全策略时提示
rules:
  - rules:
      - given: response
        match:
          type: word
          condition: contains
          value: probe123xyz
      - given: response
        match:
          type: word
          condition: not_contains
          value: content-security-policy
    condition: and
    issue:
      severity: low
      confidence: tentative
      detail: 标记被反射且未观察到内容安全策略，建议人工复核输出上下文
​

结构自上而下三段：定义段给检查起名描述；规则段是主体，本例两个子规则分别做"反射存在"与"头部缺失"两个信号匹配，condition 声明两信号同时成立；问题段定义命中条目的三要素——严重度、置信度、给未来读者看的说明。注意置信度这里如实填了疑似级：规则只知道"两个信号同现"，不知道业务上下文，这条检查的定位是线索生成器而非结论生成器——与 4.2 节的分级处置哲学一脉相承。

多步请求也是支持的：按顺序声明若干请求，后面的请求可引用前面响应里提取的值，会话类的两步检查（先取值、再带值验证）写起来仍然只是声明。

案例实录：把一次人肉经验变成规则

背景。4.2 节复核那条疑似跨站脚本时，你确认过"靶场前端对属性上下文做了实体转义"。这个观察对所有基于反射的误报都有降噪价值——下一次扫描若能自动带上"检查转义是否存在"这一步，疑似条目会先被分好类。

操作。把上面的定义稍作扩展：规则一匹配响应中是否存在实体转义后的探测标记，规则二匹配原样标记，条件用"或"——两者必居其一，命中后产出一条信息级条目，描述里写明两种命中分别代表什么。写完用编辑器的校验功能检查语法，然后对一个确认过的页面做小范围试跑。

结果。试跑对已转义页面正确产出"已转义"信息条目，对未转义的练习页面产出"原样反射"条目。

解读。这条规则没发现任何新漏洞，但它把一次人工判断变成了可复用的机器判断——这正是防御视角下工具思维的典型落点：检测经验的沉淀比单次发现更有长期价值。团队可以把这类规则集中管理，代码库式地维护：命名统一、描述写清判定依据、改动留说明，半年后新人接手才不至于面对一堆天书规则。

变式。规则成熟后有两种去向：留在扫描器里作为每次审计的固定成员；或者作为检测思路输出给防御侧，写成网关与监测系统的对应规则——第六章蓝队视角会正面讨论这条路径。

💡 给每条自定义检查写清"它不懂什么"（业务上下文），未来的使用者才知道它的条目该怎么处置。

规则的调试与试跑流程

写完的规则不能直接信任，调试按三步走。语法校验：编辑器内置的校验先过一遍，结构错误在此拦截。小范围试跑：把审计目标临时收窄到一个已知行为的页面——比如 4.2 节那条已确认转义的留言板——规则应在它身上产出预期条目；正反两个已知样本（一个该报、一个不该报）都过一遍，是规则调试的最小完备测试。规模试跑：在靶场全站跑一遍，观察条目的查准与查全，同时记录耗时——规则的执行成本也是成本，低价值高频触发的规则会稀释审计预算。调试期的经验值得写成注释放在规则描述里：当时为什么这么设计、在哪个样本上验证过。规则是可以传承的代码，注释就是它的交接文档。

规则库的治理节奏

当规则多起来，治理问题随数量而来。命名规范先行：统一的命名让规则列表可扫读，按业务域或检测类型分类。生命周期管理：每条规则标一个状态——在用、试运行、停用——停用的规则不删除而是归档，它们记录着检测思路的演化史。评审机制：新规则上线前过一眼同行评审，重点看置信度标注是否诚实、描述是否说清"它不懂什么"。与 5.1 节的插件审查对照会发现有趣的对称：插件是别人写的代码要审，规则是自己写的检测也要审——审查的对象是判断逻辑，与作者无关。治理做得好，规则库就是团队检测经验的总账；做得不好，它就是一堆半年后没人敢删的谜语。

高频疑问

问：BChecks 与扩展插件的功能边界到底在哪条线？
答：看两件事：状态复杂度与运行时机。单次或线性多步、声明可表达的检测归 BChecks；需要维护跨请求状态、动态计算、界面交互的归插件。拿不准时先试 BChecks，表达能力不够再升级——降级容易升级难，反过来则返工。

问：规则误报了，修规则还是改流程？
答：先看误报的形态：上下文类误报（规则本身表达不了）说明规则定位该降为线索生成器；特征类误报（匹配写宽了）修匹配条件。修完按调试三步重跑，误报的教训同样写进注释。

问：规则能分享给其他团队吗？
答：可以，声明式文件天然可分享。分享时补齐三样：适用环境的说明、验证过的样本描述、已知的误报形态——不带上下文的规则输出是负资产。

与后续章节的接口

到本节，自动化一侧的能力拼图完整了：你设计的批量、行业库的扫描、你沉淀的规则。第五章把视角抬到工具之外——扩展生态与自动化边界，讨论哪些环节交给机器是赚、哪些是亏。

本节要点回顾

• 定位：声明式检查补的是"业务口径的初筛"，复杂逻辑仍归扩展模块。
• 结构：定义、规则（信号匹配加逻辑组合）、问题三要素，置信度如实标注。
• 沉淀：人肉确认过的判断固化成规则，检测经验资产化是长期主义的做法。
• 管理：规则库按代码标准维护，写清判定依据与适用边界。