子域名接管到底是什么：从数据流看它的边界

子域名的 CNAME 仍指向第三方，而那个资源已经被释放，就存在被他人重新认领的风险

理解它的关键是画出三条线：入口、信任边界、危险点。

先说结论

漏洞的本质是「不可信数据到达了危险点」，防御的本质是「在中间加一道能正确判断的关卡」。

• 入口：数据从哪来，谁都能改吗
• 边界：跨边界时有没有做类型与格式判断
• 危险点：拼接、解析、执行、反序列化
• 前置条件：需要什么权限、什么配置
• 影响面：能读到什么、能改到什么

数据流：从入口到危险点

接管之后能拿到同源信任：主域的 Cookie 作用域与 CSP 白名单都会认这个子域，站点与邮件是同一条链。

信任边界在哪

邮件域的子域名被接管，可以被用来发送能通过 SPF 校验的信件，收件方很难识别。

边界两侧的数据可信度不同，所有校验都应该发生在边界上，而不是散落在业务代码里。

这个问题的几个关键事实

决定它「是理论还是现实」的几条：

• 对象存储的桶名全局唯一，释放之后名字可以被任何人重新注册并绑定，成本接近于零
• 资产台账里已经停用的业务，DNS 记录往往没人清理，是最常见的来源

影响面怎么判

评估危害时先问：需要什么身份、需要开什么配置、能不能碰到内网。三个问题的答案决定了它是「低危」还是「要连夜修」。

为什么总是修不干净

下线业务只删了服务器，DNS 记录留在原处

以为没开 HTTPS 就没风险，同源信任不看证书

根因通常是「同一个入口有多个解析器」，修了一个，另一个还通。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 子域名的 CNAME 仍指向第三方，而那个资源已经被释放，就存在被他人重新认领的风险
• 每月比对一次 CNAME 目标是否还能解析，是成本最低的发现手段，下线流程里要加一步 DNS 回收
• 只查主域，忘了外包团队申请的二级子域

理解数据流，比背 payload 有用得多。