DataTables CDN宕机事件复盘

2025年7月29日，DataTables.net 网站因域名被劫持而发生重大服务中断。攻击者通过社会工程手段，诱骗域名注册商将域名所有权转移，导致主站、论坛及 CDN 服务下线。尽管服务器和用户数据始终安全，但此次事件对全球依赖其 CDN 服务的用户造成了广泛影响。事件的核心教训在于，即使服务器本身固若金汤，域名等外部依赖环节的脆弱性也可能导致灾难性后果，社区和开发者应采取如子资源完整性（SRI）和文件自托管等措施来增强安全性。

事件回顾：域名被劫持

此次攻击的目标并非网站服务器，而是 datatables.net 的域名本身。攻击者并未攻破服务器或窃取任何数据，而是通过欺骗手段，让域名注册商将域名从合法所有者账户中转移到了攻击者控制的账户下。

• 用户数据安全： 服务器从未被入侵，你在 DataTables.net 上的任何账户信息都是安全的。
• 源代码安全： DataTables 的源代码安然无恙。
• 核心问题： 攻击者获得域名控制权后，修改了域名服务器（DNS）记录，将网站流量指向了他们控制的服务器，导致服务中断。

攻击手法：一次精心策划的社会工程

攻击者没有使用任何技术手段破解账户，而是完全通过欺骗域名注册商来达到目的。整个过程可以分解为以下几个步骤：

• 邮件轰炸： 攻击者从六月中旬开始，向网站所有者的一个旧邮箱每分钟发送三封垃圾邮件，持续不断。这旨在用海量无关信息淹没真正重要的通知。
• 伪造身份： 攻击者在同一家域名注册商那里注册了一个账户，并使用一个看起来与所有者邮箱极为相似的地址。随后，他们提交了伪造的驾照和水电费账单（信息可能来自泄露的 WHOIS 数据）来证明身份。
• 发起转移： 注册商接受了伪造的身份证明，并启动了域名转移流程。
• 错失警告： 注册商按流程向所有者的邮箱发送了域名转移确认邮件，但这封关键邮件被之前攻击者制造的垃圾邮件洪流所掩盖。
• 默认同意： 在五天内未收到任何回复后，注册商的系统默认同意了转移请求，域名被成功劫持。

这次攻击的教训是，安全链条的强度取决于其最薄弱的一环。在这种情况下，薄弱环节是依赖于人工审核和默认策略的域名转移流程。

CDN 中断的巨大影响

如果只是一个文档网站下线，虽然令人烦恼，但影响有限。然而，此次事件的严重性在于 DataTables CDN 的中断。

• 广泛的应用： 全球大量开发者在其项目中使用免费的 DataTables CDN 来加载 Javascript 和 CSS 文件，因为它方便、快速且免费。
• 庞大的流量： 该 CDN 每月处理约 55TB 的数据传输和 34.4 亿次请求。
• 连锁反应： CDN 的瘫痪意味着无数依赖它的网站和应用无法正常加载关键资源，导致功能失常或页面崩溃。

经验教训与给用户的安全建议

这次攻击暴露了一个意想不到的攻击向量——针对服务提供商的社会工程。为了防止类似事件再次发生，所有人都应采取行动。

网站所有者已采取的行动

• 将域名注册商的所有邮件标记为高优先级，确保不会错过。
• 向注册商建议，域名转移请求的默认操作不应是“接受”。
• 为域名添加了 DNS 监控，补充现有的 HTTP 和 ping 监控。

你可以采取的行动

• 使用子资源完整性 (SRI)： 在加载外部 Javascript 和 CSS 文件时，务必添加 integrity 属性。这能确保浏览器加载的文件内容与你预期的完全一致，未被篡改。DataTables 的下载生成器已自动提供 SRI 哈希值。

• 考虑自托管文件： 与其依赖外部 CDN，不如将所需的文件下载到你自己的服务器上托管。这虽然增加了些许不便，但让你对核心资源拥有完全的控制权，不受第三方服务中断的影响。

• 警惕异常信号：

  > 如果你的某个邮箱突然收到海量的注册或订阅邮件，请务必警惕——这很可能是攻击者为了掩盖某些重要通知而发起的“噪音攻击”。