fable-security

Fable Security

推理攻击者可控的路径和信任边界，直到每项安全发现都有明确的来源、汇点、前提条件和影响。

使命

安全审查不是秘密扫描加一份通用检查清单。它要查明攻击者可以控制什么、该输入能跨越哪些权限／数据边界、必须满足哪些强制约束，以及在故障和并发情况下，变更后的代码是否仍能保持这些属性。

扫描器未发现问题，只能证明扫描器覆盖范围内的情况，不能证明设计安全。

适用场景

• 身份验证、授权、会话、令牌、权限、租户隔离或特权操作发生变更；
• 不可信输入进入解析器、查询、模板、文件、URL、Shell、Webhook 或反序列化器；
• 处理机密信息／凭据或加密材料；
• 差异变更了信任边界、网络暴露面、存储访问、软件包／安装逻辑或沙箱；
• 需要验证已报告的漏洞／发现或校准其严重性；
• 需要对仓库／软件包供应链行为进行安全审查。

不适用场景

• 任务仅涉及功能验证，不涉及安全问题（fable-verify）；
• 通用可维护性审查不涉及信任边界（fable-review）；
• 漏洞已验证，用户只需要范围明确的修复（fable-execute，同时保持安全验收标准）。

安全工作分类

模式	核心问题
威胁建模	存在哪些资产／参与者／边界／滥用路径？
安全差异审查	此差异改变了什么安全属性？
发现验证	攻击者可控的数据是否确实能到达敏感汇点？
仓库审计	哪些暴露面值得深入检查？
机密信息卫生	敏感值是否可能进入源代码／日志／构建产物？
供应链／软件包	依赖／安装／构建边界是否可能遭到滥用？

流程

阶段 1 — 确定资产、参与者和信任边界

识别：

• 受保护的资产／数据／操作；
• 已验证身份／未验证身份／特权参与者；
• 租户／用户所有权边界；
• 外部系统／Webhook／插件；
• 进程／文件系统／网络权限转换。

没有明确边界的安全结论通常过于含糊。

阶段 2 — 跟踪攻击者可控输入及其影响

针对每个相关入口，依次跟踪： 来源 → 解析／规范化 → 验证 → 授权 → 转换 → 敏感汇点／副作用

记录每项安全属性的强制执行位置，以及后续转换是否可能使先前的验证失效。

阶段 3 — 检查适用于该边界的属性

根据相关情况，考虑：

• 身份验证与授权的区分；
• 对象／租户所有权（IDOR/BOLA）；
• CSRF／状态绑定和重定向验证；
• 注入／查询／模板／Shell 边界；
• 路径遍历／符号链接／归档文件解压；
• SSRF 及 URL／DNS／重定向处理；
• 文件上传的内容／大小／存储／执行边界；
• 反序列化／解析器资源滥用；
• 会话／令牌过期、重放、轮换、受众／签发者；
• 日志／错误／构建产物中的机密信息；
• 故障时默认放行的错误处理；
• 竞态／TOCTOU 及先检查后执行的授权；
• 通过配置／插件／钩子实现的权限提升；
• 依赖／安装脚本／供应链假设。

阶段 4 — 建模故障和替代路径

思考：

• 验证服务发生故障时会怎样？
• 默认行为是拒绝，还是代码会继续执行？
• 重试是否会重复执行特权操作？
• 攻击者能否在检查与使用之间更改状态？
• 后台任务是否会重新检查授权，还是信任调用方过时的声明？
• 重定向／代理／解析器是否会在验证后转换该值？

阶段 5 — 审慎验证发现

对每个候选发现，明确以下事项：

• 攻击者所需的前提条件／控制能力；
• 可达的数据源；
• 确切的接收点／特权效果；
• 缺失或被绕过的控制；
• 现实可行的利用路径；
• 影响／范围；
• 可能使问题不成立或降低严重性的现有缓解措施。

不要仅仅因为存在危险 API 就报告漏洞。

阶段 6 — 校准严重性

严重性取决于可利用性、获得的权限、数据／租户范围和所需条件，而非仅由扫描器标签决定。

对于可行且可利用、并违反必要安全属性的问题，使用 blocking。对于不确定的候选项，应标记为需要验证，而不是夸大其严重性。

阶段 7 — 提供有据可查且范围明确的修复建议

修复建议应指出需要恢复的属性以及如何证明该属性，例如：在变更前以原子方式强制校验租户所有权；在解析符号链接后确保路径仍在限定范围内；对规范化后的目标应用重定向允许列表。

阶段 8 — 将安全与功能分开处理

安全证据可以阻止发布，但不能替代功能测试、构建或运行时证据。修复后，可能还需要进行安全专项验证和功能验证。

决策规则

• 身份验证能证明身份，但不能证明用户对某项资源／操作拥有授权。
• 应尽可能在敏感副作用发生前就近进行验证／授权，尤其是在跨越异步／后台边界时。
• 如果转换可能改变含义，应先规范化／标准化，再进行范围限制／允许列表检查。
• 对受限的目标／操作，应优先使用允许列表／能力检查，而非阻止列表。
• 从当前源代码中删除的密钥，仍可能存在于 Git 历史记录／日志／构建产物中；如果密钥确实可能已暴露，应轮换已暴露的凭据。
• 若扫描器发现的问题不存在可达的攻击者可控路径，并不意味着它一定可利用；应验证从数据源到接收点的路径。
• 扫描器未发现问题，并不能消除设计层面的授权／逻辑威胁。
• 不要对真实系统执行破坏性利用载荷；应使用安全的本地／测试夹具证明，或通过代码路径推理。
• 如果修复会改变产品行为，应交由 TDD／execute 处理，并要求之后进行功能验证。

不变量

• 证据或日志中绝不复现原始密钥。
• 每个报告的漏洞都有具体的失效属性和可达路径，否则应明确标记为尚未验证。
• 租户／资源授权应独立于登录状态进行评估。
• 除非明确转为修复工作，否则安全审查应保持只读。
• 功能正确性与安全正确性始终属于不同的证据类别。

故障分类

误报

存在危险原语，但攻击者无法控制数据源／到达接收点，或缓解措施能阻止利用。应根据证据降低级别或删除。

隐藏的信任边界转换

代码跨越队列／插件／代理／后台／存储边界，并假定上游已完成验证。必须追踪并重新验证所需属性。

故障时默认放行

控制操作出错／超时后，流程会继续执行特权行为。应将其视为高优先级的边界失效。

检查与使用之间的时间差／竞态

授权／范围检查与副作用之间存在间隔，且可变状态可能发生变化。应寻找原子操作或重新验证。

清理不一致

在解码／规范化／重定向／符号链接解析之前就进行了验证。应在接收点边界检查规范化后的值。

密钥暴露

凭据进入了源代码／日志／构建产物／历史记录。应移除暴露途径，并视情况要求轮换凭据／控制影响范围。

反模式

• “没有高危 CVE，因此是安全的”；
• 不追踪变更路径的通用 OWASP 检查清单；
• 将已通过身份验证的用户等同于已获授权的用户；
• 在规范化解析路径之前进行正则表达式路径检查；
• 仅因请求到达 Webhook 端点就信任 Webhook 字段；
• 报告没有攻击者路径的理论性 API 风险；
• 为调试身份验证而记录原始令牌；
• 未经授权就在生产环境中测试漏洞可利用性；
• 为了通过测试而禁用验证或扩大权限，以此修复安全问题。

安全发现报告

Security property:
Asset/boundary:
Attacker prerequisites:
Source → transformations → control → sink:
Concrete failure scenario:
Existing mitigations:
Severity + rationale:
Evidence/location:
Bounded remediation property:
Security re-test:
Functional verification still required:

完成标准

满足以下条件时，安全工作即告完成：

• 已追踪相关信任边界和攻击者可控路径；
• 已验证并校准候选发现，而非仅通过模式匹配得出；
• 分析过程中未泄露机密；
• 阻断性发现有明确范围的修复和验证标准；
• 结论准确说明了检查的安全属性，以及仍未检查的内容。

延伸资源

• 深入指南：references/trust-boundary-and-finding-validation.md
• 现有威胁矩阵：references/threat-modeling-matrix.md
• 机密信息卫生：references/secret-sanitization.md
• 示例：examples/security-audit-walkthrough.md