【翻译】XS-Leaks攻击简介

今天在读SP的一篇文章Cross-Origin State Inference (COSI) Attacks:Leaking Web Site States through XS-Leaks的时候，发现对作者使用的XS-Leaks攻击不理解，而且国内博客资料也很少，因此我去Google了一下。在这里，把我的查阅的资料翻译一下，并写下我的理解。后面，我会附上SP那篇论文的论文笔记。

历史¹

在10年前，Chris Evans描述了一种针对Yahoo!Mail攻击。这是一个基于network timing的攻击，攻击者让受害者进行一次查询询问，通过访问返回时间的长短，来判断用户是否在攻击者预设的列表中。
六年后，Nethanel Gelernter和Amir Herzberg对这一攻击进行了深入的研究，并设计了XSSearch攻击。攻击不断改进，这次攻击不在仅仅限于时间，浏览器的“错误特性”和漏洞使得攻击更加稳定，这使得攻击达到近乎完美的程度。

攻击的核心是检测一个查询询问是否有结果。 XS-Leaks利用了对HTTP缓存进行查询的机制。

举例¹

1. Delete the cache for a specific resource (or list of resources).
   首次，使用POST请求或者提取API与缓存一起使用：``重新加载’’（reload），以一种在服务器上返回错误的方式（例如，通过设置一个超长的HTTP引荐来源网址） ，这将导致浏览器不缓存响应，并使先前缓存的响应无效。
2. Force the browser to render a website (navigation, or prerender).
   强制受害者浏览器访问一个网站。这个网站是攻击者设计的网站，访问该网站会使得受害者访问要检查的网页。在一定情况下，攻击者会缓存要检查的网页的资源。
3. Check if the browser cached the resource deleted at (1).
   再次强制受害者浏览器访问攻击者实际的网站，但URL非常长，服务器是无法返回有效的资源的。不过在其中嵌入的图片会因为已经被缓存在客户端，所以可以访问。由此可以判别，用户是否缓存该资源。
   

应用场景²

看了上面的攻击过程，感觉没啥用处，因为为什么要知道是否受害者缓存过什么资源呢？
下面这个应用场景给了我们答案。

• 攻击者目标：获取受害者社交网站的用户名，以确定受害者在社交网站中的身份。（因为在现实生活中，人们在社交网站上使用虚假的名字，我们无法定位到这个人是谁。）
• 攻击过程
  0. 清空HTTP缓存资源。
  1. 使攻击者访问恶意页面。其中恶意页面需要加载受害者在某社交媒体平台的照片。该照片会保存在HTTP缓存中，并以受害者用户名命名。
  2. 使攻击者访问恶意页面，然后需要加载/tim.png的照片出来，但是由于本地缓存没有，因此无法加载；然后需要加载/alice.png的照片，由因为刚好是Alice，因此加载成功。
  3. 看到加载成功的结果，攻击者可以断定，受害人是Alice。
     

防御¹

重要的是，希望不同域应该访问不同域的缓存。

1. 禁用HTTP缓存
2. 在所有的内容上加上CSRF tokens
3. 可以使用Same Site=strict cookie对用户进行身份验证。
   等等

---

1. HTTP Cache Cross-Site Leaks: ↩︎ ↩︎ ↩︎

2. Web tracking via HTTP cache cross-site leaks ↩︎