网络攻击的常识里，打死一台服务器需要海量流量，安全团队 FoxIO 十月二十日公开的新研究把这个常识撕了个口子。他们命名了一类针对 HTTP/3 的放大攻击，头部手风琴，攻击方只发几百 KB 级别的数据，服务端就要为此分配天量内存，小水管打出大水枪，枪还是借服务端自己的手。小众软件二十二日做了报道。我核了研究原文、各实现的官方公告与修复状态，站长视角的应对清单如下。
漏洞原理
HTTP/3 用 QPACK 压缩请求头，机制本意是省流量。攻击者的玩法分两步，先往动态表里插一个巨大的头部条目，再用一个字节的短索引反复引用它。协议规定每个字段按名字加值再加三十二字节开销计数，服务端照这个口径预留内存，但引用一次，实现就要全量分配并复制一次，账面记一粒米，仓库搬一座山，山还不用攻击者自己出力气。研究员测出的最高放大比是四千零六十四比一。测试的十个实现里七个中招，同一个协议条款，七家写出五种违反姿势，协议文本与工程实现之间的缝隙被这次研究照得透亮。
杀伤力多大
数字全部来自研究团队自测，按自称口径听。某运行时单条流约五百 KB 就触发整数溢出死循环，处理器满载永不恢复。同一家约五点八兆流量即可让两 GB 内存的容器被系统杀掉。另一实现不足十兆流量加五十个连接，一秒内钉死五 GB 内存。小众软件标题里那句几百 KB 卡死服务器，出处就在这里。对照传统拒绝服务动辄 GB 级的流量需求，这类放大攻击的性价比高得吓人，防御方按流量清洗那套老办法基本没用，病根在服务端的内存账本上，账本不改，清洗只能治标。
谁中招，谁没事
中招名单按使用面排，排在最前的覆盖面最广。一个广泛使用的开源 QUIC 库有编号漏洞，修复版零点五七，用它构建的反代与隧道软件是站长层面影响最广的一批。某云厂商的开源 QUIC 库修复于零点二十九点三。抓包工具、某新兴运行时、两个协议库也中招，截至披露仍未修复，名单留在这几家手里等着补，补完名单就翻篇。干净的三个里有谷歌的实现、某商业服务器与一个纯 C 实现。给这些库排座次是为了一个实际问题，你的网站用的反向代理、隧道客户端、边缘节点，底层是哪家的 QUIC 栈，决定你要不要动。
站长升级清单
教学向给可执行的核对步骤。第一步，盘家底，列出对外开 HTTP/3 的组件，反代、边缘、隧道挨个过，一个都别漏。第二步，查依赖，确认底层 QUIC 库版本，用到那家开源库的必须零点五七以上，云厂商系零点二十九点三以上，另一系四点九以上。第三步，处理修不了的，尚未修复的那几个实现，官方建议要么别对外暴露 HTTP/3，要么直接关掉这个协议开关，抓包工具有对应参数可关。改完记得重启服务生效。自测有无问题，自家内存曲线在低流量时异常飙升，就是一个值得追查的信号，追查的起点从这里开始。
解决了什么需求
这类协议层漏洞最麻烦的地方是看不见，流量监控一切正常，内存却莫名耗尽，排障方向容易被带偏。研究给出的价值有三层，给运维一张带版本号的核对表，给开发者一堂协议实现课，给行业一个提醒，压缩与引用机制天生是放大器的温床，写实现的人要按恶意方重来一遍内存账。普通读者也不妨记个名词，下次看到服务器莫名卡死，先想想协议层，说不定就少走一天弯路。
一句收尾，小流量掀翻大服务，这类攻击提醒我们补丁要打在依赖的最底层。
来源
- 小众软件报道 https://www.appinn.com/http3-header-accordions
- FoxIO 研究原文 https://foxio.io/blog/header-accordions-qpack-amplification-attacks-against-http-3-servers
- 漏洞数据库记录 https://osv.dev/vulnerability/GHSA-g754-hx8w-x2g6
- 云厂商库公告 https://github.com/cloudflare/quiche/security/advisories/GHSA-4fgf-9xrr-88gf
- 概念验证代码 https://github.com/FoxIO-LLC/blog_poc