通过浏览器缓存bypass同源策略（SOP)

Posted 2021-04-14 microdesktop

错误的配置能导致严重的漏洞，

举例，攻击者能用通过中间服务器（反向代理，负载均衡，缓存服务器）去获得敏感数据，

另外一种攻击方式是通过web缓存投毒去溢出缓存。

浏览器缓存看起来非常安全的去临时储存私有信息。

主要的风险是攻击者通过文件系统获得私有信息，

然而在许多案例中，

错误的配置缓存相关的http头也能导致严重的危险案例。

跨域交互风险

许多网站有许多子域，但是子域之间需要共享数据，

然而在同源策略（SOP）下是不可能的，

有许多方法可以实现跨域交互，

举例 JSONP,用这种方法的开发者一定要实现某种保护来对抗信息泄露

让我来说一个例子，

一个站点有二个子域blog.example.com和account.example.com，account.example.com 网站有一个json，

根据用户的cookie 返回该用户的敏感信息，

为了防止信息泄露，

通过白名单列表(blog.example.com)验证了header头的Referer 的字段，

如果诱惑用户访问恶意网站，

攻击者是无法直接偷取敏感数据的，

而然 ，如果jsonp 设置了缓存相关的headers头，

攻击者就能通过web缓存获得私有信息。

浏览器行为

不同的浏览器的缓存实现略微不同，

但是某些方面也相似。

首先，只有GET回复包会缓存，

当浏览器获得GET请求的回复包，会检测回复包的包头：

    1.如果回复包里面包涵Cache-Control:private或者Cache-Control: public 头，缓存会通过 Cache-Control:max-age=<seconds>来缓存。

    2.如果回复包里面包涵  Expires头, 缓存会通过他的值来缓存（他的优先级低于Cache-Control）

    3.如果当前回复包没有上面列出的字段, 一些浏览器会检测 Last-Modified 头 和通常会缓存当前日期和Last-Modified日期差的10%

    4.如果没有任何和缓存相关的头, 浏览器也许会缓存回复包，但是用的时候会重新验证

主要问题是一个浏览器会缓存所有网站数据，

他们只是通过一个标准版key(scheme://host:port/path?query)去获取数据,意味着没有任何附加信息(比如javascript函数或者标签,以及cookies,或者http头)来获得敏感信息 ,

任何网站只要发送相同的URL就能获得缓存account.example.com回复包

攻击步骤解析

手把手的利用攻击步骤说明：

    1.用户访问blog.example.com.

    2.blog.example.com的脚本需要用户账号的信息

    3.用户浏览器发送一个jsonp的请求到account.example.com.

    4.jsonp回复一个站点account.example.com包涵缓存相关的包

    5.用户浏览器缓存了这个回复包

    6.用户被诱导访问一个有毒的网站

    7.这个有毒的网站包涵一个jsonp的脚本来获得account.example.com的用户信息

    8.浏览器返回缓存的回复包给这个有毒的网站

在这个案例中，Referer头永远不会检测，

因为回复包来自缓存。

而然攻击者通过缓存获得了用户的私有信息

Similar Vulnerabilities

类似的漏洞

这个方法可以用来溢出XSSI和过同源你攻击，

这个攻击也能过服务器端检测，举例，Origin头，

相同站点的cookie属性，或者定制包头

让我们来假设account.example.com 用CORS来替换JSONP,

他返回一个Access-Control-Allow-Origin: *的头，

但是通过定制包头用一个特别的token来授权用户来保护敏感数据

如果返回包来自缓存，攻击者通过构造相同的URL也能盗取私有信息,

没有CORS保护（由于Access-Control-Allow-Origin: *），

用户浏览器没有检查定制用户头的token就直接返回缓存数据。

怎么对抗SOP泄露

sop泄露是配置错误导致的

在Cross-origin交互中，你应该屏蔽浏览器缓存，

许多框架和现成的脚本不会设置缓存相关的头或者设置默认（Cache-Control: no-store）

 而然，你应该双层检测他们的安全，

浏览器开发商也应该考虑实现一个严格的途径去缓存，

希望这将改变当前的Cross-origin信息泄露