漏洞总结：通过不受信任的 X-Forwarded-Host 标头进行密码重置中毒导致账户接管和 2FA 绕过 漏洞概述 该漏洞源于 AzuraCast 的 中间件无条件信任客户端提供的 HTTP 标头，且未使用受信任的代理白名单。攻击者可以通过注入此标头来毒化发送给用户的密码重置链接。当受害者点击该链接时，重置令牌会被发送到攻击者的服务器，攻击者随后利用该令牌在真实实例上重置受害者密码并销毁其 2FA 配置，从而实现完全账户接管。 根本原因： 1. 无条件信任： 代码直接读取 标头，未验证请求是否来自受信任的反向代理。 2. 安全关键 URL 使用请求主机： 在 为 true 时，生成的绝对 URL 使用了被毒化的请求主机。 3. 密码重置生成绝对 URL： 重置邮件中的链接使用了被毒化的主机。 4. 重置令牌销毁 2FA： 重置密码时，用户的 2FA 密钥被无条件销毁。 影响范围 受影响版本： (Composer) <= 0.23.5 严重程度： 高 (8.1 / 10) CVSS 指标： 攻击向量 (Network)、攻击复杂度 (Low)、特权要求 (None)、用户交互 (Required)、范围 (Unchanged)、机密性 (High)、完整性 (High)、可用性 (None)。 后果： 任何用户账户（包括管理员）的完全接管，无需预先认证。 2FA 绕过：密码重置流程无条件销毁 2FA 配置。 如果目标是管理员，可导致管理权限的滥用。 修复方案 1. Fix 1 (Primary): 验证 X-Forwarded-Host 受信任代理白名单 在 中，仅在请求来自受信任代理（如 Docker 内部的 nginx）时才应用 标头。 2. Fix 2 (Defense in depth): 为安全关键电子邮件使用配置的 base URL 在 中，使用配置的 设置生成重置 URL，而不是请求派生的 URL。 或者修改 以添加选项来强制使用配置的 base URL。 3. Fix 3 (Defense in depth): 不要在密码重置时销毁 2FA 在 第 75 行，移除 。如果需要 2FA 恢复，应作为单独的显式流程处理，而不是密码重置的副作用。 POC 代码 前置条件： 一个启用了 2FA 的 AzuraCast 实例用户账户（例如 ）。 攻击者控制 并记录传入请求的 Web 服务器。 步骤 1: 触发中毒的密码重置 预期结果： 发送给 的密码重置邮件包含如下 URL： 步骤 2: 捕获令牌 当受害者点击邮件中的链接时，浏览器导航到 。攻击者的 Web 服务器 捕获完整的 URL 路径，提取令牌 。 步骤 3: 在真实实例上使用令牌 结果：** 受害者的密码更改为 ，其 2FA 被销毁 ( )。攻击者以完全访问权限登录。