Web 安全之 Cookie Bomb 攻击详解

Cookie Bomb 攻击，又称“Cookie炸弹”，是一种针对客户端的拒绝服务（DoS）攻击。攻击者通过在用户的浏览器中设置大量或体积巨大的Cookie，使得浏览器向服务器发送的HTTP请求头变得异常庞大，超出服务器的处理能力上限，从而导致服务器拒绝该用户的请求，导致用户无法正常访问网站。

攻击原理

Cookie Bomb 攻击的核心原理在于利用了 HTTP 协议和 Web 服务器的限制。当浏览器向服务器发送请求时，会将与该域名相关的 Cookie 一同放在 HTTP 请求头（HTTP Header）中发送过去。为了防止资源滥用和恶意攻击，几乎所有的 Web 服务器都会对请求头的大小设置一个上限，例如 Apache 服务器默认是8 KB，Nginx默认为4-8 KB。

攻击者正是利用了这一限制。攻击流程通常如下：

1. 寻找注入点：攻击者首先需要找到可以在目标用户浏览器中设置 Cookie 的漏洞。最常见的方式是利用目标网站或其子域下的跨站脚本（XSS）漏洞。即使是目标主站本身没有漏洞，其任何一个子域名（例如 blog.example.com）的 XSS 漏洞都可能被用来设置针对主域名（.example.com）的 Cookie。

2. “投弹”：即设置恶意Cookie，找到注入点后，攻击者会编写并执行一段恶意的 JavaScript 代码。这段代码会在用户的浏览器中创建大量的 Cookie，或者创建一个或少数几个但包含大量垃圾数据的Cookie。由于 Cookie 可以设置Domain属性，攻击者可以将这些恶意的 Cookie 设置到目标主域名下。

3. 引爆“炸弹”：当受害用户的浏览器再次尝试访问目标网站（例如 www.example.com）时，就会自动携带所有与 .example.com 相关的 Cookie。由于攻击者已经“投下”了大量的垃圾 Cookie，这会导致HTTP 请求头的体积非常大，轻松超过服务器设置的上限。

4. 拒绝服务：服务器在接收到这个超大的请求头后，会因无法处理而拒绝该请求，并通常会返回一个错误，如 400 Bad Request 或 431 Request Header Fields Too Large。从用户的角度来看，就是网站无法访问、加载失败或不断报错，从而达到了拒绝服务的目的。

Cookie Bomb 攻击的危害

与传统的 DDo S攻击（分布式拒绝服务）动辄需要海量僵尸网络不同，Cookie Bomb 攻击更为隐蔽和精准，其主要危害包括：

• 针对性强：该攻击可以精确地针对单个用户进行，使其无法访问服务，而网站对其他用户而言仍然是正常的，这使得攻击更难被发现。
• 影响范围可控：攻击者可以通过设置Cookie的Path属性，将攻击范围限制在网站的特定页面或功能，例如只让用户无法访问其个人中心或购物车。
• 难以追溯：攻击流量直接来自受害者本人，服务器日志只会记录到来自受害者IP的异常请求，增加了攻击追溯的难度。
• 影响持久：除非用户手动清除浏览器Cookie或者Cookie过期，否则攻击效果会一直持续。对于普通用户而言，通常不会轻易清除所有网站的Cookie，因此可能长时间无法访问受影响的网站。
• 业务影响：对于高度依赖用户登录和交互的网站，如电商、在线金融服务等，这种攻击可能导致用户无法完成交易、无法管理账户，从而造成直接的经济损失和品牌声誉损害。

如何防御 Cookie Bomb 攻击？

防御 Cookie Bomb 攻击需要从客户端和服务器端两个层面进行综合考虑和设防。

服务器端防御策略

1. 合理配置请求头大小限制：

   • 根据业务实际需求，为 Web 服务器和应用服务器设置合理的请求头大小上限。这个值不宜过大，也不宜过小，需要在安全和功能之间找到平衡点。
   • 定期审查该配置，确保能满足正常业务需求，同时又能有效阻挡异常请求。

2. 部署Web应用防火墙（WAF）：

   • 配置 WAF 来检测和拦截异常的 HTTP 请求。可以设置规则，当检测到请求头中的 Cookie 数量或总大小超过一个合理的阈值时，直接拦截该请求。
   • WAF 可以作为第一道防线，有效保护后端的 Web 服务器。

3. 清理和限制 Cookie 设置：

   • 在应用层面，避免将非必要的信息存储在 Cookie 中，减小正常 Cookie 的大小。
   • 对应用程序可以设置的 Cookie 数量和大小进行监控和限制。虽然主要依赖浏览器执行，但服务器端可以在逻辑上进行追踪和报警。

4. 加强子域名的安全管理：

   • 严格审计所有子域名的安全性，修复存在的 XSS 等漏洞，防止攻击者利用子域名“曲线救国”。
   • 使用__Host-或__Secure-前缀来创建 Cookie，可以将 Cookie 的作用范围锁定在当前主机名，而不是整个父域名，从而阻止子域对主域的 Cookie 污染。

客户端防御策略

1. 客户端脚本监控：

   • 可以在网站前端部署 JavaScript 代码，通过 document.cookie 来监控 Cookie 的数量和大小。
   • 当发现 Cookie 数量或大小异常增长，超过预设阈值时，可以主动进行清理，移除可疑的 Cookie，或者向服务器发送警报。

2. 内容安全策略（CSP）：

   • 严格配置 CSP，限制页面可以执行的脚本来源，可以极大地减少 XSS 漏洞被利用的风险，从而根除Cookie Bomb 的注入源头。

对用户的建议

对于普通用户而言，如果怀疑自己遭遇了 Cookie Bomb 攻击（表现为特定网站无法访问，但网络正常且其他网站可以访问），可以尝试以下操作：

• 清除特定网站的 Cookie：在浏览器的设置中找到 Cookie 管理选项，搜索目标网站的域名，并删除所有相关的 Cookie。
• 使用无痕模式访问：无痕模式或隐私模式通常不会加载已有的 Cookie，可以临时用来验证是否是Cookie 问题导致的访问故障。

小结

Cookie Bomb 攻击虽然不像大规模 DDoS 那样引人注目，但其精准、隐蔽和对用户体验的直接破坏性，使其成为 Web 安全领域一个不容忽视的威胁。开发者和运维人员需要对其有充分的认识，并采取多层次的防御措施来保障服务的可用性和安全性。