4月17日 | 【NDSS 2020】Melting Pot of Origins

最新推荐文章于 2024-05-30 14:09:36 发布

丫丫二_97

最新推荐文章于 2024-05-30 14:09:36 发布

阅读量852

点赞数

分类专栏： web安全文章标签：安全 web

本文链接：https://blog.csdn.net/Sunny_Ducky/article/details/105586997

版权

web安全专栏收录该内容

27 篇文章 1 订阅

订阅专栏

Melting Pot of Origins: Compromising theIntermediary Web Services that Rehost Websites

原文：link
作者：

Takuya Watanabe
Eitaro Shioji
Mitsuaki Akiyama 上学期还读了他的一篇文章~
Tatsuya Mori
lab：NTT 这个网站过于复杂，不想看了

Abstract

web服务中介，例如Web代理，Web翻译和Web档案已经成为人们无处不在使用的工具，极大的提高了网络的开放性。作者认为这些服务为网络托管服务，作者对这些服务进行了首次大规模漏洞研究。作者发现了五个不同种类型的攻击：持续的中间人攻击，滥用特权以访问各种资源，偷盗身份信息，偷盗浏览器历史记录和会话劫持/注入。

Introduction

作者本片论文研究的主要对象是三个网络托管服务：web proxy, web translator, web archive（Web归档使用户能够访问以前发布的Web内容的某个版本，该版本由于过期、维护或阻塞等各种原因目前不可用。）

网络托管服务增强了网络的可访问性，由于用户可能会在网络托管服务上输入隐私信息，因此攻击者可能会产生利用网络托管服务的动机。本篇文章是第一次针对具有托管属性的网站进行大规模的研究，并发现常见的安全问题。并且基于此问题，作者提出了一个PoC攻击模型，并验证了其可行性。

攻击的核心想法利用了一个事实由网络托管服务提供的域名是可以被用来访问各种托管网站的；这种“melting pot of origins”情况允许攻击者绕开同源安全策略的过滤。通过使用这种攻击，作者发现可以展开多种攻击。

作者又进一步检查了21中流行的web托管服务并检查是否存在这种漏洞。作者发现其中19个存在。

Background

Web Rehosting in the Wild

图1展示了对web托管服务的流程。这个有点像服务器的代理。作者起名为web托管服务，作者将托管服务分为了三大类：web代理，web翻译和web档案。
在这里插入图片描述
表一总结了本次工作中研究的21个Web托管服务。（作者在供应商的要求下匿名了两个应用）

Advanced Web Features

Service Worker Service Worker是现代web的一个特征。它是JS写的一个事件驱动的web worker。它与主浏览器线程独立工作，并提供丰富的功能，例如后台数据同步和推送通知处理。Service Worker的一个显着特征是它可以代理Web客户端和服务器之间的所有请求和响应，并修改内容。因此，它提供了非常强大的功能。

一个Service Worker内在的实施了很强的安全限制来防止它强大的功能被利用：

在安全的环境中被操作，如HTTPS或者本地
遵守SOP，仅可以对在其路径包含Service Worker脚本或更低版本的URL上运行。
浏览器要求Service Worker脚本的MIME类型仅为JS，text/javascript, application/javascript, 和application/x-javascript; 否则不可使用。

Application Cache HTML5标准提供了一套应用程序缓存机制，这允许web应用程序离线运行。有三大优势及其相关的要求：

Offline browsing, 离线浏览AppCache提供缓存替代资源，而不是由于网络或服务器错误而显示的后备页面。在2016年AppCache被启用，但是2019年9月，还有很多最新的浏览器支持这项功能，对其的约束与Service worker相似，唯一的不同就是AppCache在同源的页面上工作时，不依赖于其路径。
Speed,
Reduced workload.

Browser Permissions web浏览器支持访问各种各样的资源，如地理定位，相机，麦克风，和通知，访问这些资源需要用户的许可。这里有一个假设，就是不同的域名运行着不同的访问资源策略。然而，通过Web托管服务授予的访问权限违反了此假设。

Browser-based Password Managers 之前的论文笔记介绍了基于浏览器的密码管理服务，这里不做赘述。这里强调的是，由于密码管理器时通过检查域名来识别其所用密码的，对于web托管服务来说，由于它使用的是单一的域名托管多个网站，这可能会违反密码管理器所做的基本假设，即不同的网站应具有不同的域名。

Pitfalls of Cookies

在这里，作者列举了攻击所需Cookies的缺陷。

Access from JS 如果设置了HttpOnly标志，且HttpOnly成功的话，那么JS脚本就不可以接触到Cookie，但是大部分网站这个标志被设置为false。
Session Cookie 如果没有设置过期的日期，那么cookie会变成会话cookie，技术上来讲会话cookie会在浏览器关闭后被删除。但是实际上，在浏览器中配置“Continue where you left off”设置将使会话保持活动状态。
Cookie Bomb Web服务器拒绝那些请求头太大的请求。如果对于一个网站有太多太大的cookies，服务器通常会返回一个错误。

Threat Model & Attacks

Threat Model based on Origin Unification

如图所示是托管服务中对于不同域名设置网页的原理。托管服务会将原始的资源转换为具有相同源的页面。当SOP有效时，evil.example是无法获取到a.example和b.example的资源的，但是托管服务会将页面映射到相同源的，此时SOP将不再有用。

攻击过程：

攻击者构造URL为https://rehosted.example/rehost?url=https://evil.example的包含恶意脚本的网页，并使其运行。
攻击者通过传统的Web攻击场景（下载、网络钓鱼和跨站点请求伪造，垃圾邮件，恶意媒体链接的帖子）诱导受害者访问恶意页面。这里需要注意，某些网络重新托管服务会通过验证引荐来源网址或HTTP会话来禁止进行热链接（即直接链接到重新托管的页面），这增加了攻击的攻击的难度。
触发攻击

为了使得攻击更加有效，攻击者可以使用一个登录页面，这个页面嵌入的多种iframe标签指向由各种web托管服务代理的恶意页面。通过单独访问这一个页面，攻击者便可实现利用多个托管服务实现攻击的场景。而这个登陆页面时不需要被托管的。对于模拟域名有几种选择：通过缩短的URL进行包装或重定向服务，并通过XSS和网站伪造将其注入合法站点。
在这里插入图片描述

Attacks against Web Rehosting

基于以上攻击模型，作者提出了广泛存在于web托管的5中类型的攻击。如下图所示，作者将其分为两种类型：

利用资源来了解哪些网络托管用户之前（即在访问之前）已经读/写过，
从此时开始（即访问后）寄生化资源以监视和篡改受害者的浏览器。

Persistent MITM

作者发现，一个攻击者可以再web托管服务提供的源上注册一个恶意的service worker。

如下图所示，是为一个普通的HTML注册了一个service worker。在这种情况下，根路径下的sw.js被注册为在web托管源路径下的sw.js。
在这里插入图片描述
攻击者注册了一个恶意的service worker。

当受害者访问被托管的恶意页面时，MITM攻击成功。如下图所示。服务人员可以执行各种攻击方案，例如修改新文章的细微差别，替换电影，注入广告，显示网络钓鱼页面以及用恶意软件替换下载的文件。
在这里插入图片描述
和传统的MITM相比，新MITM攻击能力更大。因为，无需直接拦截网络路径上的通信，service worker注册成功后便会进行永久窃听，并且对于哪些启用HTTPS的页面也会受到影响。

不幸的是，现代浏览器并没有一一个容易被用户理解的表现来检查service worker。

为了检车service worker是否被注册，一个用户需要打开开发者攻击，并且小心地检查Service Worker的设置。

以上是针对Service worker的，对于AppCache，攻击者无需Service worker便可进行持久性MITM攻击。与上面的攻击类似，攻击手首先重新托管一个恶意的清单文件，然后重新托管一个HTML文件，这个HTML文件包含有重新托管清单文件的URL。之后，作者写入fallback规则在清单文件中，需要列出两个URL：第一个是要重写的页面（可用通配符），第二个是备用页面。（如下图所示，*是需要被重写的页面，第二项是通配符）
在这里插入图片描述
注意，这两个源是相同的。当返回错误状态码时，AppCache才会启用备用重写机制。但是我们之前提到过，当浏览器发送给服务器的消息头中包含很大的cookies时，会返回错误码，此时触发攻击。在上面的示例中，攻击者甚至通过AppCache篡改了受害者通过Web托管服务访问的所有页面。

下表是两个方法的区别。
在这里插入图片描述

Privilege Abuse

在存在Web托管的情况下，对于硬件的访问权限，如相机或者GPS可能会被共性到整个托管的网页。
在这里插入图片描述
此外，攻击者可以在经通知许可通过分发Web Push通知来组合恶意service worker。通知可以包括钓鱼、恶意图片和恶意网站URL链接的信息。

Credential Theft

保存在浏览器中的密码的信任凭据与网页的源相关。如果用户使用web托管服务登录某个网页，那么这个账户的密码可能就会与信任凭据相关，当受害者访问恶意的web托管服务页面是，页面的恶意JS代码就会盗取自动填入登陆框的信息。注意到，浏览器是否填写登录表单，除了与页面源有关，而且与form的设计有关（上篇论文也有提到），因此攻击者需要精心设计一个与真正页面相似的表单。

History Theft

对于现代浏览器而言，使用JS代码和使用本地存储是非常常见的。数据会根据源的不同存储在本地不同的位置。而使用托管服务的页面会共享cookies和local storage。攻击者可以利用这些数据（key-value）来对受害者访问过的网站进行指纹识别，进而，受害者用户的浏览历史被攻击者窃取。攻击者甚至可以通过cookie的过期时间来判断目标用户访问网页的时间。

Session Hijacking and Injection

web代理依赖于HTTP头中的cookies来保证浏览器和原页面间的HTTP会话。Web代理会将新的cookie放在HTTP头中，当用户使用Web代理登录到一个固定的服务中时，浏览器会存储Web代理提供新的cookie。在这种情况下，攻击者可以使用JS窃取此cookie，然后劫持来自代理恶意网页的原页面的HTTP会话。注意到，虽然HttpOnly可以阻止这种情况的发生，但是大多数代理服务并没有使用HttpOnly。

一个攻击者也可以在受害者浏览器中注入一个会话，并且强制受害者登录一个账户。

会话劫持仅适用于通过网络托管服务主动登录到Web服务的用户，而会话注入适用于未自行意愿登录服务的用户。作者注意到受害者可能怀疑会话注入，因为他们将在登录到攻击者准备的陌生帐户时浏览服务。

Rehosting Rules

由于上述五种攻击依赖于Web托管的规则。作者介绍了常用的web托管规则，以及攻击者如何滥用这些规则来操纵浏览器资源。

URL Rewriting 最基本的规则就是URL重写规则。Web托管服务主要为托管的页面提供两种类型的URL命名约定：URL查询惯例（使用Web代理和Web转换器）https://rehosted.example/rehost?url=evil.example；UNIX路径之类的约定。https://rehosted.example/evil.example/。对于使用前者的URL重写，service worker可以作用于所有托管页面，攻击成功。另一种则不行。
Rehostable File Type web代理和Web档案服务可以用原始MIME类型托管任何类型的内容。在这种情况下，攻击者可以放置一个恶意的service worker或AppCache 清单文件在源托管文件中；对于翻译服务，当JS脚本被放置在scr属性和script标签中，那么自动会被托管，以防止内容混乱带来的安全问题。在这种情况下，在src属性中的URL被转换为重定位JS的URL，因此一个攻击者可以使用一个恶意serviceworker脚本放在源托管页面。
Handling Browser Resources 虽然被托管页面的源变为由web托管服务所提供，但是JS代码不会被重写。因此，所以保存在良性页面JS代码中的资源和许可都可以被恶意页面访问到。
HTTP头中的cookies依赖于web托管属性。Wayback Machine通过向标头名称添加特定前缀（例如x-archive-orig-set-cookie）来禁用cookie存储。其他的web档案托管和翻译服务仅仅丢弃Set-Cookie的头部。Web代理隐式或显式中继HTTP头中的cookie，以便在浏览器和托管页面之间重建HTTP会话。如下图所示。

这两种cookie方法都透明地维护web浏览器和web服务器之间的HTTP会话。作者的攻击可以直接劫持会话或为显式中继cookie的web代理服务注入会话id。对于隐式中继cookie的web托管服务，作者的攻击仍然可以劫持会话或注入generatedsession id，尽管原始会话id是隐藏的。

FEASIBILITYANALYSIS

Vulnerable Rehosting Services in the Wild

作者对于21个web托管服务进行了研究。其中18个服务包含了上述类型攻击产生的漏洞。
3个web托管服务不允许热链接，限制了攻击的可行性。

有三个类型的web托管服务使用了HTTP协议，这种将会收到典型的MITM攻击；有13个服务存在持久性MITM攻击漏洞，12个是由Service worker攻击产生的。

作者还发现了一个有趣的现象，谷歌翻译有一个特点，就是会翻译用户上传的文档。如果这个页面包含漏洞，并且存在长久的service worker，那么攻击者可能会盗取用户文档中的信息。

作者还发现一部分网页，没有攻击者利用service worker进行攻击的漏洞，或者没有使用URL查询惯例重写机制。此时攻击者会转为AppCache攻击，并且攻击成功。

作者注意到Google，Yandex，Bing，Baidu和PROMT提供的翻译器将托管的内容放置在iframe中，该内容受沙箱属性保护。这些服务可以抵御特权滥用攻击，但其余服务容易受到攻击。作者发现，在所有被调查的Web代理服务中都存在credential theft attack的漏洞。此外，对于所有已启用JavaScript的调查服务，盗窃浏览历史记录是可行的。

对于所有的web代理服务，劫持session和注入攻击者会话是有效的，甚至是采取了隐式攻击的Sitenable Web Proxy和ProxFre。

对于Weblio和Wayback Machine，一个用于不可以登录一个托管服务的网页因为这些服务不算是web代理，用户仍可以登录他自己的服务。这些服务为登录用户提供额外的功：例如，Weblio提供了一本词汇书或一个查看考试结果的控制台，而Wayback Machine允许用户查看上传或收藏的网页列表。作者发现，可以使用类似于Session Hijacking and Injection中描述的过程劫持服务本身的登录会话。

Evaluation of Fingerprinting

在本节，作者评估了browsing history theft使用的fingerprinting技术的影响。作者评估了三个方面：网站的可识别性；指纹的生命周期；指纹是否泄露了用户的访问时间。

检测指纹可用性的网站 作者检查了cookie中，本地存储中以及JSON dictionary中是否包含指纹泄露的情况，网站作者选择了Alex 排名Top-10K的网站。作者使用代理站点进行了实验。作者发现，通过我们提出的指纹可唯一识别的网站比例为39.1％（2,541）。作者列出了可指纹网站的前10个类别。该观察结果表明，攻击者可以通过 history theft attack来估计受害者的概况。此外，作者还发现了可识别指纹的网站，包括色情、约会和盗版等敏感网站。
指纹的生命周期 为了研究时间对指纹唯一性的影响，作者进行了一项模拟用户访问网站后删除过期Cookie的实验。作者假设用户访问每个网站一次。
图6显示了网站指纹可用性的变化。显示了两种情况：所有会话cookie都处于活动状态以及它们何时过期。当经过时间为零时，可用指纹的百分比为100％（对于活动会话cookie）和96.4％（对于过期的会话cookie）。在一天的用户访问后，该百分比分别下降到69.4％和64.2％。不需要长时间存储的Cookie的有效期通常少于24小时。第二天后下降趋势变得温和，因为具有长寿命的cookie和持久的localStorage密钥有助于指纹的唯一性。
由于一些网站以月为单位设置到期日期，例如1个月、2个月或3个月，我们可以看到在第30天、第60天和第90天出现小峰值。
Fingerprints 泄露用户访问时间 由于cookie的过去时间等于访问时间加上一段时间，而访问时间就可以等于cookie过期时间减去增量。这可使得攻击者能够得到用户的访问时间。结果，作者发现73.6％的指纹泄漏了访问时间。
每个浏览器的资源访问行为 作者在这里讨论了不同的浏览器的资源访问行为和他们对攻击成功和失败的影响。下表是作者研究的浏览器。
对于询问。如果浏览器提示ask once，将会有很大的滥用特权的风险，因为一旦资源访问被允许，他将不会再询问。对于标签为selective，当使用者选择yes时，攻击者才可以开始实施攻击。
对于密钥自动填充。标记为“自动填充”的浏览器会在页面加载时自动使用保存的密码填充密码字段，从而使凭证盗窃变得可行。而标记为“手动”的浏览器将焦点集中在登录表单元素上，但除非用户明确指示，否则不会填充，在这种情况下攻击不会发生。
关于会话cookie，标记为“keep by default”的浏览器在退出浏览器时不会删除会话cookie；标记为“keep by config”的浏览器在通过更改配置以保存退出选项，这种情况下不会删除会话cookie。这两种情况下，攻击者将会有一个很长的机会盗取session cookies，由此受害者可能会有很高的收到session劫持攻击和history theft攻击的风险。

DISCUSSION

Coverage of Our Experiments 作者在这里分析了它检查的web托管服务的全面性。
Human factors 在本文中，作者提出了一个通常存在于这些服务中的严重威胁，并证明了许多服务实际上是脆弱的。另一方面，作者并没有从用户实际使用这些服务的角度来考察。但是作者给出了充分的实例，说明他们的假设是成立的。
Ethical considerations

DEFENSES

All Atacks 解决此威胁的直接方法是，不仅使用单独的域名来分隔托管的网站，而且还为每个托管的网站生成一个不同的子域。但是对于已经托管的网站，可以生成一个第三方无法访问的临时URL。这种情况下，就无法将页面进行共享。
将浏览器转为私有模式是一种有效的对策，可以在用户端采取措施，以完全阻止或减轻我们的某些攻击。
Persistent MITM 需要限制service worker和AppCache行为。Web托管服务器可以通过拒绝浏览器标头中Service-Worker: script具有此头的请求，来阻止恶意服务工作者的注册。因为现代的托管服务都没有利用Service-Worker工作，因此这种方法不会付出代价。AppCache，攻击利用了HTML标签，在托管的页面中强制删除此属性应防止其滥用。
Privilege Abuse. 将其加载到沙盒属性的iframe内，可以确保用户不授予对Web托管的权限。某些服务（例如Google Translate）已经采用了此方法。
Credential Theft. 针对密码管理器的一种可能的防御方法是将凭据与域路径对关联，而不仅仅是域。但是，只有少数浏览器才采用了此功能。
History Theft 由于History Theft取决于网站指纹的准确性，因此防止指纹成为防止攻击的关键。防止网站指纹的一种可能方法是从所有重新托管的网页中强制删除调用对Cookie或localStorage的访问的JS代码。这种方法并不完美，因为已知要彻底检测混淆的JavaScript代码非常困难。更积极的方法是删除所有JavaScript代码，但这可能会导致网站外观或功能严重恶化。
Session Hijacking and Injection 因此，可以通过启用HttpOnly属性来防止将它们从重新托管的恶意网站中的JavaScript代码加载。这是使用XSS缓解会话劫持的常规措施。