浅谈XS-Leaks之Timeless timing attck

最新推荐文章于 2025-12-12 16:05:37 发布

原创

最新推荐文章于 2025-12-12 16:05:37 发布 · 968 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#web安全 #安全 #前端

本文详细介绍了XS-Leaks，一种利用Web平台内置侧通道的漏洞，以及与CSRF的区别。重点探讨了Timeless Timing Attack，这是一种不受网络抖动影响的远程计时攻击。文章通过HTTP/2的多路复用机制和报文封装，展示了如何实施Timeless Timing Attack，强调了其在远程攻击中的优势。此外，还通过实例解析了如何在实际场景中利用Timeless Timing Attack进行信息泄露探测，包括HTTP/1.1协议下的可能性。最后，文章讨论了攻击的总结和未来可能的拓展方向。

本文首发于先知社区，转载请联系对方
原文链接：浅谈XS-Leaks之Timeless timing attck

文章目录

1 XS-Leaks简介

1 什么是XS-Leaks？

Cross-site leaks（又名 XS-Leaks、XSLeaks）是一类源自 Web 平台内置的侧通道的漏洞。他们利用网络的可组合性核心原则，允许网站相互交互，并滥用合法机制来推断有关用户的信息。

2 XS-Leaks和CSRF的区别

XS-Leaks 和 csrf 较为相似。不过主要区别是 csrf 是用来让受害者执行某些操作，而xs-leaks 是用来探测用户敏感信息。

3 XS-Leaks的利用原理和使用条件

浏览器提供了多种功能来支持不同 Web 应用程序之间的交互；例如，它们允许网站加载子资源、导航或向另一个应用程序发送消息。虽然此类行为通常受到 Web 平台中内置的安全机制（例如同源策略）的限制，但 XS-Leaks 会利用网站之间交互过程中暴露的小块信息。

XS-Leak 的原理是使用 Web 上可用的侧信道来探测有关用户的敏感信息，例如他们在其他 Web 应用程序中的数据、有关其本地环境的详细信息或他们连接到的内部网络。

设想网站存在一个模糊查找功能（若前缀匹配则返回对应结果）例如 http://localhost/search?query=，页面是存在 xss 漏洞，并且有一个类似 flag 的字符串，并且只有不同用户查询的结果集不同。这时你可能会尝试 csrf，但是由于网站正确配置了 CORS，导致无法通过 xss 结合 csrf 获取到具体的响应。这个时候就可以尝试 XS-Leaks。虽然无法获取响应的内容，但是是否查找成功可以通过一些侧信道来判断。

这些侧信道的来源通常有以下几类：

浏览器的 api (e.g. Frame Counting and Timing Attacks)
浏览器的实现细节和 bugs (e.g. Connection Pooling and typeMustMatch)
硬件 bugs (e.g. Speculative Execution Attacks 4)

一般来说，想要成功利用，需要网页具有模糊查找功能，可以构成二元结果（成功或失败），并且二元之间的差异性可以通过某种侧信道技术探测到。

补充一下，侧信道(Side Channel Attck)攻击主要是通过利用非预期的信息泄露来间接窃取信息。

2 网络计时攻击-network timing

1 传统的计时攻击

想象这样一个情景，受害者有权限访问一些报告，当受害者访问我们的网站，我们发出两个请求：

查询一个不可能存在的字符
查询一个需要确认是否存在的字符

当发现查询的时间有差异时，我们就能推断出这个字符存在于报告中的某个地方；同理，当两个请求返回的时间相同，说明该字符不在。

但现实环境并没有那么理想，根据29th usenix 上的这篇论文Timeless Timing Attacks: Exploiting Concurrency to Leak Secrets over Remote Connections，传统的基于时间的攻击主要受到以下一些因素影响：

基于攻击者与服务器间的网络因素
- 高的网络延迟会带来比较差的攻击效果。（尽管攻击者可以使用离目标服务器物理位置比较近的 VPS 或者同一个 VPS 供应商来解决这个问题）
网络延迟在上游下游都有可能产生
时间差是决定传统时间攻击是否能够成功的重要因素
- 例如监测 50 ms 就要比 5µs 要简单
需要大量的测试请求

一般来说判断延迟所需要的请求数量：

也就是说在这种情况下，我们可能需要发送成百上千的请求才能判断是否存在信息泄露，并且它仅仅只能判断一个字符。这不仅需要发送大量请求，而且在整个攻击过程中受害者需要持续访问我们的的网站以及一些其他的限制。

2 Timeless timing

1 原理

在整个攻击流程中，我们想要知道的是查询所需要的时间，这个过程发生在服务端。而我们测量的地方在客户端，这中间会发生许多的网络交换，这个过程无法避免，因为我们不能直接在服务器上测量时间。

事实上，我们在意的并不是两个查询各自花费了多少时间，我们在意的是哪一个花费的时间更长！

这里我们假设有两个报文 A 、 B，后端服务器在接受到 A 时会产生延迟，接受到 B 时不会产生延迟，这篇论文主要通过以下方式解决了传统时间攻击的这些问题：

通过报文同时发出来尽可能使其同时到达来避免通信过程中产生的网络抖动影响(由于攻击者不能控制低层的网络协议，所以我们需要其他方法来让两个请求在同一个packet内)
- 这里可以有两个选择：多路复用以及报文封装
  - 多路复用：可以通过 HTTP/2 并发流机制来达到这一个目的，使其尽可能在同一时间被发送并尽可能在同一时间到达。（比如 HTTP/2 与 HTTP/3 开启了多路复用，HTTP/1.1 并没有）其中尽量还要满足一个报文可以携带多个请求到达服务器这么一个条件
  - 报文封装：这种网络协议可以封装多个数据流（例如 HTTP/1.1 over Tor or VPN）
通过测量两个报文的返回顺序来代替传统攻击中测量报文所需时间
- 对比 AB 两个报文哪一个先返回来判定哪一个受到了延迟，而不是通过测量哪一个报文用了多少时间
- 此时要求服务器、应用拥有并行处理的能力，目前大多数都可以满足这个要求

如果我们可以满足同时发出两个报文 AB 并且他们也同时到达，Timeless Timing 攻击需要做的就是重复多组发送报文的操作，并统计他们返回的先后顺序，如果服务器处理两个报文后没有产生延迟的现象，那么这两个报文会被立即返回，因为返回顺序不受我们控制，并且可能受到返程通信过程中的网络影响，所以返回的先后顺序概率为 50% 及 50% 。

如果服务器在处理 B 报文时会差生延迟现象，诸如比 A 要多进行一遍解密、查询等耗时的操作，那么 B 会比 A 要稍晚才能返回，这样一来，尽管响应报文在通信过程中仍然会受到一些影响，但是我们可以多次测量来统计这个概率，此时 B 比 A 先返回的概率回明显小于 50% ，于是我们可以通过这个概率来判断两个请求是否在服务器处理时产生了延迟。

并且论文当中也对比了传统时间攻击与 Timeless Timing 攻击之间的各自区分一定时间延迟所需要的请求：

还是可以很明显的看出timeless timing在同样探测精度下所需要的请求数量要少很多。

2 优点

基于并发的Timeless timing attck不受网络抖动和不确定延迟的影响
远程的计时攻击具有与本地系统上的攻击者相当的性能。

3 题目讲解

简单示例

在此之前我们可以先看一个demo

a starting point for our exploit: https://github.com/DistriNet/timeless-timing-attacks

我们可以使用仓库中给的示例代码：

from h2time import H2Time, H2Request
import logging
import asyncio

ua = 'h2time/0.1'

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger('h2time')

async def run_two_gets():
    r1 = H2Request('GET', 'https://tom.vg/?1', {
   
   'user-agent': ua})
    r2 = H2Request('GET', 'https://tom.vg/?2', {
   
   'user-agent': ua})
    logger.info('Starting h2time with 2 GET requests')
    async with H2Time(r1, r2