Web Timing 和竞争条件攻击：揭开隐藏的攻击面
在传统的 Web 应用中，漏洞的发现和利用通常相对容易理解。如果代码存在问题，我们可以通过发送特定输入来强制 Web 应用执行非预期的操作。这种情况下，输入和输出之间往往有直接关系：错误的输入导致错误的输出，表明存在漏洞。
但是，如果我们只使用合法的数据就能找到漏洞呢？如果问题不在于数据本身，而在于数据的发送方式呢？这就是 Web Timing 和竞争条件攻击的领域。让我们一起探索这个迷人的隐藏攻击面！
1. 什么是 Web Timing 攻击？
从本质上讲，Web Timing 攻击是通过观察 Web 应用处理请求所需时间的长短来获取信息。我们可以通过微小的输入变化或调整发送方式来测量响应时间的差异，从而获得未经授权的信息。
竞争条件攻击的特殊性
竞争条件（Race Condition）是 Web Timing 攻击的一个子集，但更加特殊。在竞争条件攻击中，我们的目标不仅仅是获取信息，还希望利用漏洞让 Web 应用执行非预期的操作。
例如，当一个用户多次同时提交相同的优惠券请求时，可能会因为 Web 应用的处理方式缺陷，导致该优惠券被多次使用。
Web Timing 漏洞的复杂性
Web Timing 漏洞往往非常微妙。根据研究，响应时间差异可能从 1300 毫秒到 5 纳秒不等，这种细微的差异需要各种测试技术才能检测出来。然而，随着 HTTP/2 的普及，这类漏洞变得稍微容易发现和利用。
2. HTTP/2 的崛起
HTTP/2 是 HTTP 协议的重大更新版。虽然大多数 Web 应用仍在使用 HTTP/1.1，但越来越多的应用转向 HTTP/2，因为它速度更快、性能更好，并引入了一些克服 HTTP/1.1 限制的新功能。然而，如果这些新功能的实现不当，可能会被威胁行为者利用。
HTTP/1.1 与 HTTP/2 的关键区别
在 HTTP/2 中，支持“单数据包多请求”（Single-packet Multi-requests）功能。这一功能使得网络延迟不再是检测 Web Timing 漏洞的障碍。在 HTTP/1.1 中，网络延迟可能掩盖了 Web Timing 的问题，但 HTTP/2 能将多个请求打包到同一个 TCP 包中，完全消除了网络延迟的影响。
通过排除网络延迟，只剩下服务器处理请求的延迟，这使得我们更容易检测和利用时间差异以恢复敏感信息。
3. 常见的 Timing 攻击类型
Timing 攻击通常分为两大类：
信息泄露
通过观察响应延迟的差异，攻击者可以发现自己无权访问的信息。例如，利用响应时间差异枚举应用的用户名，从而帮助实施密码猜测攻击，最终获取账户访问权限。
竞争条件
竞争条件与业务逻辑漏洞类似，攻击者可以诱导应用执行非预期的操作。但竞争条件问题的根源在于 Web 应用处理请求的方式。例如，如果我们多次快速提交相同的优惠券请求，在应用尚未更新优惠券状态时可能重复使用优惠券。
竞争条件实例：检查与使用时间差 (TOCTOU)
让我们通过一个实例来解释“检查与使用时间差”（Time-of-Check to Time-of-Use，TOCTOU）漏洞：
- 用户提交优惠券代码。
- 在 Web 应用的代码中，会先检查优惠券的有效性以及是否已被使用。
- 应用折扣后，更新优惠券状态为已使用。
但在第 2 步和第 3 步之间存在几毫秒的时间差。如果攻击者能同时发送两个请求，在第一个请求更新优惠券状态之前，第二个请求可能会再次验证并应用同一张优惠券。
这种竞争条件攻击不仅可以被用于优惠券滥用，还可能在银行交易、库存管理等多种场景中造成重大安全隐患。
总结
Web Timing 和竞争条件攻击展示了现代 Web 应用隐藏的攻击面。随着 HTTP/2 的普及，这类漏洞的检测和利用变得更具可能性。开发者应采取更严谨的设计和测试方法，特别是在处理并发请求和时间敏感逻辑时。
通过了解这些攻击方式，我们不仅可以提升防御能力，还能更深入地理解 Web 应用的安全挑战。
