用单包攻击拿下 Web 竞态条件漏洞

Sun, 05 Jul 2026 00:00:00 +0000

大多数文章告诉你，竞态条件是"检查（check）与使用（use）之间的一段时间窗口"。没错，但没用 —— 因为你的 race 攻击失败，原因并不是你没搞懂这个概念，而是这个窗口比互联网的精度还要小。

一个典型的 race 窗口 —— 应用读取 balance 与写入 balance - amount 之间的间隙 —— 以微秒到几毫秒计。而当你在同一瞬间发出两个 HTTP request 时，等它们到达服务器并被调度时，两者之间的抖动通常有 1 到 10 毫秒，跨公网还会更糟。于是你那些"同时"发出的 request 排成整齐的一小列到达，服务器一个一个地处理，上限保持不破，你便断定这个端点是安全的。它并不安全。你只是在服务器还没来得及表态之前，就先输给了网络抖动。

利用 Web race 的全部功夫，就是一场让 N 个 request 在同一瞬间到达的搏斗。赢下它，那个"无法利用"的上限就会在一击之间崩塌。

为什么最后字节同步始终差那么一点

那个老式的 HTTP/1.1 技巧 —— 最后字节同步 —— 能让你接近目标：开约 20 个连接，把每个 request除最后一个字节以外的部分都发出去，然后一起发出所有的最后字节。它管用，多年来一直是最先进的做法。但它有一个无法修复的缺陷：这些是 20 个独立的 TCP 连接。每个都有自己的拥塞窗口、自己的路径时延、自己的内核调度。即便扣住最后一个字节，到达时间仍会被抹开几毫秒 —— 足以让你错过一个微秒级的窗口。最后字节同步把千分之一的 race 变成大概十分之一。是好了，但仍不稳定，仍然是"只有从同区域的 EC2 机器上才复现得出来"。

single-packet attack：一个 packet，零抖动

改变这一切的原语在此，出自 James Kettle 的 Smashing the State Machine 研究。HTTP/2 在一个连接上多路复用多个 request。于是你不再去竞速 20 个连接，而是：

Race-Condition on Crusader Research

用单包攻击拿下 Web 竞态条件漏洞

为什么最后字节同步始终差那么一点

single-packet attack：一个 packet，零抖动