OpenMetadata 出站 URL 验证不一致漏洞分析

OpenMetadata 出站 URL 策略执行不一致漏洞总结 漏洞概述 标题： Outbound URL policy is enforced inconsistently across webhook paths (出站 URL 策略在 webhook 路径中执行不一致) 核心问题： OpenMetadata 的 策略在决定服务器允许访问哪些出站 URL 时存在逻辑缺陷，导致策略执行不一致。主要问题包括： 1. 主机名验证逻辑错误： 策略判断的是主机文本（host text）而非连接实际使用的地址。 - 任何主机名无论指向何处都会被接受（只要不是 IP 字面量）。 - 模式匹配仅针对尾部，导致以 、 、 开头的普通公共主机名被错误拒绝。 - 测试用例 和 专门针对此问题，但测试覆盖了所有失败模式，包括错误的正向测试。 2. 覆盖范围不均： 强制验证是调用者自行决定的，导致某些路径有验证而某些没有。 - 的 方法对 External 类别有验证，但对其他类别无验证且提前返回。 - 、 、 、 等发布器无验证。 - 的 和 无验证。 - 的 有验证。 - 无验证，且构建的 无超时设置。 3. 分类过于狭窄： 当前分类仅允许 loopback 和 link-local 地址，但实际部署中需要支持： - 自托管 Keycloak 或类似 IdP，其发现文档通过同一验证器获取 SSO 设置。 - 集群网络上的 OAuth token 端点。 - 通过 Kubernetes 或 Compose 服务名寻址的 webhook 接收器。 影响范围 受影响组件： - - - - - - - - 潜在风险： - 攻击者可能利用验证不一致性绕过 URL 策略，访问内部网络资源。 - 某些 webhook 路径可能完全不受 URL 策略保护。 - 无超时设置可能导致资源耗尽或拒绝服务。 修复方案 提案： 1. 改进 ： - 解析主机并分类所有返回的地址，拒绝 loopback 和 link-local 地址，其余放行。 - 公共签名保持不变，现有调用者无需更改。 - 测试模式基于解析后的地址，而非 / / 前缀。 2. 引入 ： - 由 的 注册。 - 对每个返回地址重新分类，通过 和 governance webhook 使用相同工厂，使 sink 路由无超时。 3. 在所有写入路径验证： - 通过 的 方法移动端点检查。 - 对每个目的地类别运行检查， 和 同样适用。 4. 重新指定 header 构建器： - 剥离 cloud metadata headers（ 、 、 及其等价物）。 - 拒绝 在 header 名称和值中。 - 剥离覆盖 的 header 和 。 5. 报告出站 webhook 目的地失败： - 作为被动信号而非回显 和 逐字。 无新配置块： 分类足够狭窄，无需操作员重新启用。 备注 此更改行为：解析到 loopback 或 link-local 地址的端点将被拒绝，需要释放说明。 实践中，端点写入 时，字面量 已被拒绝，接收器在私有网络上不受影响。 现有指向 loopback 端点的订阅将开始报告失败原因，而非静默继续。 重定向跟随是第二个行为变更：端点回答 301 或 302 时，成为投递失败而非静默跟随。记录的端点已携带 ，因此失败会命名 URL 以移动。 将端点连接到已验证地址是进一步步骤，但意味着改变 JAX-RS 连接器，因此它属于 分支而非此分支。直到那时，在 dispatch 时重新验证 DNS 重新绑定而非关闭它，由 JVM 持有保留地址 30 秒的默认值帮助。 状态 状态： 已关闭（Completed） 标签： Bug, alerts and notifications, backend 项目： Shipping (Done) 分配给： manerow 里程碑： 无 关系： 无 最终决定： "We will not be addressing this. Internal slack thread for reference"（我们将不会处理此问题。内部 Slack 线程供参考）

目标达成感谢每一位支持者 — 我们达成了 100% 目标！

OpenMetadata 出站 URL 验证不一致漏洞分析

同源更多文章

目标达成 感谢每一位支持者 — 我们达成了 100% 目标！

OpenMetadata 出站 URL 验证不一致漏洞分析

同源更多文章

目标达成感谢每一位支持者 — 我们达成了 100% 目标！