Isolated and Exhausted:Attacking Operating Systems via Site Isolation in the Browser论文阅读笔记

基于站点隔离的操作系统资源耗尽攻击

一、预备知识

1.1浏览器的同源策略

源：Web 内容的源由用于访问它的 URL 的方案（协议）、主机名（域名）和端口定义。只有当协议、主机和端口都匹配时，两个对象才具有相同的源。不同文件路径与是否同源无关，某些操作仅限于同源内容，但可以使用 CORS 解除这个限制。(跨站资源共享CORS (4条消息) Access-Control-Allow-Origin跨域解决及详细介绍_Microanswer的博客-CSDN博客）

源（origin）和站（site）：

一条请求的核心部分就是这三部分：scheme（协议）+主机域名+端口，三者能够唯一标识通信方，这三部分的组成也被称为套接字（socket）。

同源，跨源：严格要求相同scheme、主机域名和端口结合的网站被认为是“同源”，其他的被认为是“跨源”。

同站、跨站：根域服务器列出了例如.com和.org这样的顶级域名（Top-level domain，简称TLD）。在上面这个例子中，站就是顶级域名TLD加上它之前的部分域名。站其实就是主机域名的限定子集：部分域名+顶级域名。然而，对于例如.con.jp或者.github.io，仅使用.jp和.io这样的顶级域名TLD来说，没办法精确标识一个“站”。并且对于一个特定的顶级域名TLD，这里也没有算法去确定可注册域名的等级。这就是为什么一系列“有效顶级域名（effective TLD，简称eTLD）”被创建出来。

整个站名被称为“eTLD+1”，例如，给定一个URL：my-project.github.io，eTLD是`.github.io`，eTLD+1是`my-project.github.io`，eTLD被认为是一个“站”。换句话说，eTLD+1是有效的TLD加上它之前的部分域名。相比于同源，同站显得相同更加宽容。

讲清楚同源、跨源、同站、跨站 - 掘金 (juejin.cn)

同源策略是一个重要的安全策略，它用于限制一个源的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。同源策略是为了安全，确保一个应用中的资源只能被本应用的资源访问。在所有浏览器的安全策略中，同源策略是最基础、最核心的策略，很多其他衍生出来的策略都只是同源策略的“补丁”，包括本文提到的其他安全策略：CORS、COOP、COEP。

document.domain 存放的是载入文档的服务器的主机名，可以手动设置这个属性，设置该属性有两个特点： 只能设置成当前域名，或者当前域的二级域名（比如 document.domain 为 www.baidu.com ，可以设置成 baidu.com ）

1.2 CSRF（跨站请求伪造）

CSRF（即跨站请求伪造）是指利用受害者尚未失效的身份认证信息、（cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害人的身份向（身份认证信息所对应的）服务器发送请求，从而完成非法操作（转账，改密码等）。CSRF属于业务逻辑漏洞，在服务器看来，所有请求都是合法正常的。XSS是基于客户信任服务器，而CSRF是基于服务器信任客户（经过身份验证的)CSRF（跨站请求伪造）的原理和防御 - 知乎 (zhihu.com)

1.3 站点隔离

Chrome 站点隔离 - 掘金 (juejin.cn)

隔离是指将系统或者资源区分开、是为了在系统发生故障时、限定传播的范围、或者减少资源竞争或者保证服务间不相互影响

站点隔离是一种安全功能，它确保来自不同站点的页面处于不同的进程中，每个进程运行在沙箱中。通过站点隔离机制，站点的隔离与操作系统级别的进程隔离保持一致，而不是通过同源策略等在进程内实现逻辑隔离。站点隔离使不受信任/恶意网站更难读取或窃取网站数据，因此提供了额外的安全保护。强烈建议用户开启网站隔离功能，因为它可以 “沙盒化网页和 Web 框架，将它们彼此隔离，从而进一步增强 Firefox 的安全性”。

URL使用IP地址的情况下，站点隔离就变回了同源比较，以实现进程隔离。

本地文件可以通过文件scheme呈现到浏览器选项卡中。目前，站点隔离将使用文件scheme的所有URL都视为源自同一站点。

data URL与传统的url不同。 传统的url在浏览器地址栏中输入，可以直接导航到目标地址；而data URL则是一个data的url表现，可以理解为用url代表数据。 通常情况下，这里的数据指代的是图片。

dataURL的显示形式 data:image/jpeg;base64,/9j/4AAQ…

Blob URL 的显示的形式 blob:域名/e61c67e3-df3a-453a-8f41-df740c1f5faf ，

Blob网址/对象网址只能在浏览器内部制作。可以通过文件读取器 API 创建 Blob 并获取 File 对象，尽管 BLOB 只是意味着 Binary Large 对象并以字节数组的形式存储。客户端可以请求数据以 ArrayBuffer 或 Blob 的形式发送。服务器应该将数据作为纯二进制数据发送。数据库通常也使用Blob来描述二进制对象，实际上我们基本上是在谈论字节数组。

为什么视频网站的视频链接地址是 blob？生产场景往往是对切片格式的视频 m3u8 地址进行 blob 格式处理，其实并不是为了加密，因为浏览器还是会解析 blob 并去 get 请求对应的 m3u8 地址，使用 blob uri 的好处在于可以在一定层度上干扰爬虫。在早期一般网站资源文件不怎么通过 referer 设置防盗链，当我们拿到视频的地址后可以随意的下载或使用。Blob URL 这个 URL 的生命周期和创建它的窗口中的 document 绑定。

1.4 DOS攻击

DOS攻击是利用程序漏洞一对一的执行资源耗尽的Denial of Service拒绝服务攻击。拒绝服务（DOS）攻击是一种旨在使网络、网站或服务失灵、关闭或中断的攻击。本质上，它意味着攻击者以某种方式阻止普通用户访问网络、网站或服务，从而拒绝他们的服务。一切能引起拒绝服务的行为的攻击都被称为dos攻击。

DOS攻击的原理：首先攻击者向被攻击的服务器发送大量的虚假ip请求，被攻击者在收到请求后返回确认信息，等待攻击者进行确认，（此处需要拥有HTTP协议工作方式和tcp三次握手的基本知识）该过程需要TCP的三次握手，由于攻击者发送的请求信息是虚假的，所以服务器接收不到返回的确认信息，在一段时间内服务器会处与等待状态，而分配给这次请求的资源却被有被释放。当被攻击者等待一定的时间后，会因连接超时而断开，这时攻击者在次发送新的虚假信息请求，这样最终服务器资源被耗尽，直到瘫痪。

1.5 DNS域名解析

DNS学习笔记 -- 缓存投毒 - 知乎 (zhihu.com)

常见的DNS攻击——偷（劫持）、骗（缓存投毒）、打（DDos） - bonelee - 博客园 (cnblogs.com)

(4条消息) 一文搞明白DNS与域名解析_dns解析和域名解析_思源湖的鱼的博客-CSDN博客

为什么 DNS 使用 UDP 协议 - 面向信仰编程 (draveness.me)

DNS服务器分为本地DNS服务器和权威DNS服务器，DNS主要是负责把域名解析为IP（www.baidu.com解析成39.156.66.18）。（其中114.114.114.114（国内移动、电信和联通 通用的DNS服务器），8.8.8.8（Google DNS服务器）这种公用DNS服务器也叫本地DNS服务器）例如，当浏览器拿到 http://www.baidu.com 需要解析时，就会问本地DNS服务器，是否知道IP地址是多少，本地DNS服务器如果知道就会直接回复，如果不知道，就会上网询问，一层一层询问，直到得到正确IP地址。当本地DNS服务器得到正确答案后，就会记录到DNS缓存中。只要缓存不过期，就会无条件信任并直接跳转。

DNS是通过UDP协议发送数据，数据格式大致如下：

[IP报头[UDP报头[DNS数据报文]]]

DNS报文的数据格式如下

DNS报文：|QID|问题区|应答区|权威区|附加区|

其中：

QID：表示查询ID，用于匹配查询报文和响应报文的

问题区：主要是所查询的问题（可以是一个或多个）

应答区：查询到问题的答案（可以是一条或多条，可以是A记录也可以是CNAME记录或NS记录）

权威区：这里主要是记录权威DNS的NS记录（可以是一条或多条）

附加区：这里存放附加的一些记录。比如在给出权威NS记录时（NS记录中没有IP），会把它的A记录放在这里（为的是防止陷入死循环）

本地DNS服务器每次查询发送的QID都是随机的

因为DNS报文是通过UDP协议发送的，所以这里是为了方便将查询和响应的内容匹配在一起

同时，对于IP不对的、UDP源端口不对的，格式不对的、QID不对的，域名不对的，应答不对的，以及其他各种莫名其妙的包，都会被本地DNS服务器抛弃

最后

查询报文，只是填写QID和问题区，后面几个区不用填写内容。

响应报文，会填写QID（和对应查询包中的QID一致）、问题区（和对应查询包中的问题一致），还会填写后面几个区：应答区、权威区（也即填写权威DNS的区域，）、附加区。

1.6 DNS缓存投毒

常见的DNS攻击——偷（劫持）、骗（缓存投毒）、打（DDos） - bonelee - 博客园 (cnblogs.com)

针对DNS转发设备的缓存投毒攻击 - 知乎 (zhihu.com)

(4条消息) 一文搞明白DNS缓存投毒_dns 0x20_思源湖的鱼的博客-CSDN博客

一次出人意料而名留青史的DNS投毒攻击 - 知乎 (zhihu.com)

DNS缓存投毒又叫DNS欺骗，是一种通过查找并利用DNS系统中存在的漏洞，将流量从合法服务器引导至虚假服务器上的攻击方式。

DNS缓存中毒CVE-2020-25686、CVE-2020-25684、CVE-2020-25685

缓冲区溢出CVE-2020-25687、CVE-2020-25683、CVE-2020-25682、CVE-2020-25681

攻击过程：

1. 攻击机器向转发器发送大量查询报文

2. 转发器向服务器查询解析域名

3. 攻击机器伪装成服务器，向转发器回复构造后的响应报文，并实现投毒

这里的问题有2个，第一是如何才能伪装成服务器，第二是怎么构造响应报文进行投毒

利用控制DNS缓存服务器，把原本准备访问某网站的用户在不知不觉中带到黑客指向的其他网站上。其实现方式有多种，比如可以通过利用网民ISP端的DNS缓存服务器的漏洞进行攻击或控制，从而改变该ISP内的用户访问域名的响应结果;或者，黑客通过利用用户权威域名服务器上的漏洞，如当用户权威域名服务器同时可以被当作缓存服务器使用，黑客可以实现缓存投毒，将错误的域名纪录存入缓存中，从而使所有使用该缓存服务器的用户得到错误的DNS解析结果。最近发现的DNS重大缺陷，就是这种方式的。只所以说是“重大”缺陷，据报道是因为是协议自身的设计实现问题造成的，几乎所有的DNS软件都存在这样的问题。

1.7 侧信道攻击

侧信道攻击中所指的侧信道信息一般为这几种：声音、温度、功耗、电磁、色彩。。。。。等等，这些信息叫做侧信道信息是因为，在加密硬件进行加密的时候，上述的信息只是加密过程中附带产生的一些物理量。包括功耗侧信道攻击，电磁侧信道攻击，风扇侧信道攻击等

1.8 套接字

Socket即套接字，是一个对 TCP / IP协议进行封装的编程调用接口（API）。它是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用以实现进程在网络中通信。TCP/IP只是一个协议栈，必须要具体实现才能被使用。通过Socket接口，我们才可以使用TCP/IP协议。我们也可以这样理解，Socket是支持TCP/IP协议的网络通信的基本操作单元，是对网络通信过程中端点的抽象表示。一文带你了解Socket - 知乎 (zhihu.com)

socket 被翻译为“套接字”，套接字是一套用C语言写成的应用程序开发库，它首先是一个库。主要作用就是实现进程间通信和网络编程，因此在网络应用开发中被广泛使用。它是计算机之间进行通信的一种约定或一种方式，是一个抽象层。通过 socket 这种约定，一台计算机可以接收其他计算机的数据，也可以向其他计算机发送数据。

socket 的典型应用就是 Web 服务器和浏览器：浏览器获取用户输入的 URL，向服务器发起请求，服务器分析接收到的 URL，将对应的网页内容返回给浏览器，浏览器再经过解析和渲染，就将文字、图片、视频等元素呈现给用户。套接字使用流程与文件的使用流程很类似，三部曲：创建套接字，使用套接字收/发数据，关闭套接字。网络套接字是IP地址与端口的组合。

1.9 DDOS攻击

一种攻击针对DNS服务器软件本身，通常利用BIND软件程序中的漏洞，导致DNS服务器崩溃或拒绝服务;另一种攻击的目标不是DNS服务器，而是利用DNS服务器作为中间的“攻击放大器”，去攻击其它互联网上的主机，导致被攻击主机拒绝服务。

DDOS(Distributed Denial Service)分布拒绝式攻击，它是在DOS基础上进行的大规模，大 范围的攻击模式，DOS只是单机和单机之间的攻击模式，而DDOS是利用一批受控制的僵尸主 机向一台服务器主机发起的攻击，其攻击的强度和造成的威胁要比DOS严重很多，更具破坏 性。首先DDOS攻击者要寻找僵尸主机，在互联网上寻找一些有后门漏洞的主机，然后入侵系统安装控制程序，入侵的越多，控制的僵尸主机就越多，攻击源就更多，然后把入侵的主机分配，一部分充当攻击的主要控制端，一部分充当攻击源，各负其责，在攻击者统一指挥下 对被攻击的服务器发起攻击，由于这个攻击模式是在幕后操作，所以很难被监控系统跟踪， 身份不容易被发现。

1.10常见的web攻击方式

十种常见的web攻击 - 知乎 (zhihu.com)

1.11 浏览器APIs

API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。简单理解： API 是给程序员提供的一种工具，以便能更轻松的实现想要完成的功能。

Web API 是浏览器提供的一套操作浏览器功能和页面元素的 API ( BOM 和 DOM )。 现阶段主要针对于浏览器讲解常用的 API , 主要针对浏览器做交互效果。 比如想要浏览器弹出一个警示框， 直接使用 alert(‘弹出’) 。因为 Web API 很多，所以将这个阶段称为 Web APIs 。

总结

1.API是为我们程序员提供的一个接口，帮助我们实现某种功能，我们会使用就可以了，不必纠结内部如何实现2.Web API主要是针对于浏览器提供的接口，主要针对于浏览器做交互效果。

3. Web API一般都有输入和输出（函数的传参和返回值），Web API很多都是方法（函数)

4.学习Web API可以结合前面学习内置对象方法的思路学习

(4条消息) Web APIs_仲夏夜的开场的博客-CSDN博客

1.12 fork bomb Dos

对进程相关资源的一种常见攻击是fork bomb ，这是一个递归地产生指数增长的克隆数量的程序。攻击者的目标是使系统过载，达到无法响应的程度，例如，由于内存页面交换或任务调度延迟。

fork炸弹以极快的速度创建大量进程（进程数呈以2为底数的指数增长趋势），并以此消耗系统分配予进程的可用空间使进程表饱和，而系统在进程表饱和后就无法运行新程序，除非进程表中的某一进程终止；但由于fork炸弹程序所创建的所有实例都会不断探测空缺的进程槽并尝试取用以创建新进程，因而即使在某进程终止后也基本不可能运行新进程。fork炸弹生成的子程序在消耗进程表空间的同时也会占用CPU和内存，从而导致系统与现有进程运行速度放缓，响应时间也会随之大幅增加，以致于无法正常完成任务，从而使系统的正常运作受到严重影响。

除了恶意触发fork炸弹破坏的情况外，软件开发中有时也会不慎在程序中嵌入fork炸弹，如在用于监听网络套接字并行使客户端-服务器结构系统中服务器端职责的应用程序中可能需要无限地进行循环（loop）与派生（fork）操作（类似下节示例程序所示），而在这种情况下源代码内的细微错误就可能在测试中“引爆”fork炸弹。

1.13 dos攻击与ddos攻击的区别

DDos、Dos攻击方式和防御方法 - 遥望星空脚踏实地 - 博客园 (cnblogs.com)

1.14 iframe

iframe是html元素，用于在网页中内嵌另一个网页

1.15 QUIC

1.16 WebRTC

我们都知道浏览器本身不支持相互之间建立信道进行通信，都需要通过服务器进行中转。比如现在有两个客户端—甲、乙，他俩想要进行通信，首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时，甲先将消息发送到服务器上，服务器对甲的消息进行中转，发送到乙处，反过来也是一样。这样甲与乙之间的一次消息要通过两段信道，通信的效率同时受制于这两段信道的带宽。同时这样的信道并不适合数据流的传输，如何建立浏览器之间的点对点传输，一直困扰着开发者。因此WebRTC应运而生。

WebRTC是一个开源项目，旨在使得浏览器能为实时通信（RTC）提供简单的JavaScript接口。说的简单明了一点就是让浏览器提供JS的即时通信接口。这个接口所创立的信道并不是像WebSocket一样，打通一个浏览器与WebSocket服务器之间的通信，而是通过一系列的信令，建立一个浏览器与浏览器之间（-to-peer）的信道，这个信道可以发送任何数据，而不需要经过服务器。并且WebRTC通过实现MediaStream，通过浏览器调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频。

同时WebRTC是一个非常优秀的多媒体框架，且支持跨平台（支持Android、IOS），能够使得Android和IOS设备作为终端设备能够像浏览器一样，进行即时通信。

1.17 websocter

WebSocket详解：技术原理、代码演示和应用案例 - 简书 (jianshu.com)

二、论文内容

2.1摘要

本论文研究了站点隔离带来的系统资源耗尽攻击问题，从下面三步展开：

1）与站点隔离直接相关的一级资源：

2）直接使用但受到浏览器沙箱保护的二级资源

3）一个先进的真实世界的攻击

对上述三步的具体措施：

1）创建分叉炸弹，展示基于站点隔离的资源耗尽攻击

2）使用高级浏览器功能，展示怎们禁用一个操作系统中的所有UDP套接字接口

3）在2的基础上，绕过一个DNS主要的安全特性，实施一个基于站点隔离的DNS缓存中毒攻击

本论文显示了现代浏览器功和旧操作之间的耦合度越来越严重，需要进一步的研究

分叉炸弹和UDP端口封锁

DNS缓存中毒

贡献：

1）描述了web攻击者如何利用浏览器中的站点隔离来对客户端操作系统进行新的资源耗尽攻击，并对攻击进行了评估

2）为证明可能的攻击超出了DOS，在web攻击者模型中实现了DEMONS(一种DNS缓存中毒攻击)。并在真实互联网环境和实验室条件下进行了验证

3）确定了站点隔离架构中的弱点，并讨论了基于站点隔离实施资源耗尽攻击的应对策略

2.2简介

站点隔离：是浏览器的安全架构，可以很好地降低来自JavaScript脚本攻击、沙箱远程执行代码和侧信道安全攻击等问题。站点隔离主要是通过将来自不同站点的渲染和脚本用不同的进程执行。

站点隔离带来的风险：在站点隔离这种方式下，浏览器和操作系统共同负责对计算和网络资源的分配。但同时，这也使得远程的web攻击者会利用站点隔离作为中介来干扰本地操作系统，会使攻击者更轻易地影响系统资源。，使得web用户在操作系统层面面临更大的风险。那么启用站点隔离是否会使操作系统更容易收到web攻击？ 启用站点隔离后，Web攻击者是否能够直接控制操作系统资源，从而绕过当前的浏览器沙箱？

攻击者模式：无网络特权，即偏离路径（不能查看、修改数据包，不能切断流量传输，无法观察、修改或阻止互联网上其他各方之间的通信。）；但可以控制自己的服务器设施，有访问服务器根目录的权利。当受害者访问部署在他们自己服务器上的网页时，及受到攻击。

如何绕过沙箱：web攻击者会受到浏览器沙箱的安全边界限制，（沙箱会控制能访问的资源边界）此沙箱通过消耗配额如HTML Web存储）、断言隐式授权（通过受信任事件）或请求显式同意（弹出窗口）来限制对资源的访问。三个步骤来克服这些障碍：

·一级资源：利用站点隔离，用JavaScript中fork bomb Dos攻击绕过浏览器监视器，对CPU和存储器进行简单的Dos攻击。

·二级资源：利用webRTC的新技术和生成新进程的简化方法，规避沙箱和性能限制，能实现封锁受害者系统上所有的可用的UDP端口。指不能直接被JavaScript和web对象直接使用的资源。单一的网络套接字可以轻易开放（如链接至支持QUIC技术的网络服务器），但在复用、超时的情况下，浏览器沙箱会阻止额外网路套接字的开放。开放较多的网络套接字会导致嘈杂的网络流量，并会增加CPU的负担，且会使浏览器变的无响应。

·高级攻击：使用站点隔离对一级资源和二级资源的攻击来实现对操作系统DNS解析器缓存的缓存中毒攻击。在2的基础上，封锁所有UDP端口后，开放一对UDP端口，并让它们被操作系统所知。操作系统只能使用这些端口用于DNS。该攻击可以避免UDP端口随机化（DNS的重要安全特性）

已知的攻击方式：

·一类：不直接攻击沙箱机制，而是直接针对机器硬件

Rowhammer.js，它使用恶意的JavaScript将故障在硬件级别注入到相邻的系统内存单元中，绕过了所有操作系统和沙盒内存访问限制

另一系列的攻击使用侧通道从其他进程或操作系统泄漏私有数据，如内存重复数据删除、击键中断和内存缓存

·二类：针对沙箱本身攻击，如 JIT spraying or fuzzing，一种从沙箱中泄漏数据的旁路攻击是JavaScript中的Spectre实现。

DNS缓存中毒攻击：UDP端口随机化是对抗Kaminski attack的唯一方式，以往进行UDP端口随机化的攻击依赖于IP碎片化和定时侧通道

主要见解：随着浏览器功能的发展，浏览器和操作系统之间的边界越来越弱。以往仅在恶意软件攻击者模式下的攻击方式开始出现在web攻击者模式中，远程、非路径Web攻击者危害操作系统，web攻击者破坏操作系统变得可能。也揭示了供应商引入的缓解措施是不够的。

2.3背景知识

2.3.1 站点隔离：

由于每个进程都会在操作系统中产生开销，因此Chrome中的Site Isolation经过优化，通过进程合并减少了进程总数。为打开的窗口创建（选项卡）创建进程，为同一站点中的每个iframe创建新的进程，同一个站点的iframe 被两个不同的窗口加载时，则只运行一个进程来呈现两个iframe。

2.3.2 可消耗的系统资源

系统端口（如53用于DNS）（0--1023）、用户端口（1024--49151）、临时端口（49152--65535）通常，OS从临时端口范围中挑选任意未分配的编号。端口号绑定到套接字后，它将在套接字的生存期内唯一标识套接字。

OS管理计算设备的资源，例如CPU时间、主存储器和网络套接字。

对进程相关资源的一种常见攻击是fork bomb ，这是一个递归地产生指数增长的克隆数量的程序。攻击者的目标是使系统过载，达到无法响应的程度，例如，由于内存页面交换或任务调度延迟。

2.3.3 DNS

DNS解析器配置又默认本地解析服务器的IP地址，首先在缓存中查找，缓存中没有则生成一个UDP socket S = (IPNS, 53, IPsrc, Portsrc)，最后由本地域名服务器返回一个目标的IP地址，域名解析器会验证并缓存该地址。解析器在请求查询时携带16位的标识ID（即TXID)，在本地域名服务器返回的结果中必须携带该标识ID进行有效性的验证。

DNS缓存中毒攻击：该攻击就是在真正的TXID返回前，用暴力破解的方式，猜出正确的TXID，使DNS内的内容受到污染。应对该攻击的的主要措施是源端口随机化，其他方法如0x20编码等，在TCP或HTTPS上实现DNS等，因为兼容性的问题并没有被广泛的应用。规避端口随机化的措施有：IP碎片整理、阻塞客户端操作系统的源端口。

2.4 基于站点隔离的资源耗尽攻击Fork Bomb Dos

未使用站点隔离的情况下，在实践中，恶意的web应用可以打开的窗口和选项卡是有限的，需要可信的事件(如，鼠标点击)来获得更多的权限。如果用户手动打开几十个窗口，操作系统或者浏览器不应该阻止这种情况，以为用户操作的表达意图以为这授权分配这些资源。

使用站点隔离后，窗口或选项卡与操作系统之间的关系变得不再简单。相反，使用站点隔离的web浏览器现在可以为每个窗口或者选项卡打开几个进程，而不需要用户交互。相关研究尝试限制这些资源的使用，但在本文中，这些方法任然可以被规避。

在站点隔离之前，浏览器通过限制每种进程的数量来保持对资源分配的控制，由于进程的数量被绑定，辅助资源分配的数量也被绑定。然而，由于web攻击者能够分配任意数量的进程，因此还可以通过利用新的站点隔离特性、边缘情况配置和实现bug的组合来克服对资源的限制。

2.4.1一级资源消耗 Fork Bomb

通过创建站点来创建进程：使用站点隔离，web攻击者能够创建任意数量的进程，尽管浏览器中存在优化和沙箱限制。这可以用于执行基于浏览器的DoS攻击，其工作原理类似于分叉炸弹，但不需要shell访问。造成这个问题的根本原因是，攻击者可以通过使用不同的域名或IP地址轻松地创建许多站点，并且每个站点都在不同的进程中呈现。

攻击概述。攻击者部署一个恶意网页，并分配了大量的IP地址IP1，...，IPN。网页（递归）包含N个iframe，源属性src设置为http://[IPi]，其中i = 1，...，N。网页本身包含一个iframe，其源属性指向IP1，每个加载的iframe包含两个其他的iframe指向不同的IP地址。使用站点隔离，加载此网页在受害者系统上创建N个进程，导致操作系统中的分叉炸弹攻击。使用IPv6地址进行相关实现。（iframe是html元素，用于在网页中内嵌另一个网页）（站点隔离：为打开的窗口创建（选项卡）创建进程，为同一站点中的每个iframe创建新的进程，同一个站点的iframe 被两个不同的窗口加载时，则只运行一个进程来呈现两个iframe）

创新点。虽然可以手动分配域名或IP地址给web服务器，但我们使用非本地绑定实现了一种更快的方法。非本地绑定是Linux内核IP堆栈的一个高级特性，它允许服务器侦听多个IP地址，而无需将它们逐个分配给网络接口。

2.4.2 第二级资源耗尽：UDP端口耗尽

通过浏览器api阻塞UDP端口（比如想要浏览器弹出一个警示框， 直接使用 alert(‘弹出’)）。我们知道有两个浏览器api可以用来阻塞网页上的UDP端口： QUIC和WebRTC。由于QUIC大量并行握手的计算成本较高，因此使用QUIC进行实验效率较低。因此，我们专注于WebRTC。

WebRTC。WebRTC是一个开放的web平台，用于电话和视频会议应用中的实时通信。从本质上说，它允许网站访问音频和视频外设（摄像头、麦克风），并提供一个API，将数据从这些设备流到使用UDP或TCP支持WebRTC的其他端点。使用会话描述协议（SDP [18]，请参见图8）交换元数据。该格式非常灵活，允许两端协商媒体通道（音频、视频或数据）的数量和类型、可能的通信端点（例如，P2P，或TURN服务器的使用）和多路复用选项。在我们的攻击实现中，我们只使用数据通道，因为视频和音频通道需要用户的显式许可，并且消耗更多的资源，不必要地增加了攻击的占用。

本地WebRTC进入准备状态。通常，sdp通过信令服务在端点之间进行交换。我们的攻击仅依赖于本地端点，因此不涉及信号服务。因为我们从未完成过任何WebRTC握手，所以我们也不需要对等对象。相反，我们只创建本地WebRTC对象，使他们进入准备状态，分配一些UDP端口以便它们为握手做准备，然后让对象闲置，只保留一个引用以被防止垃圾处理。从我们的实验来看，这是使用WebRTC对象进行端口分配的最轻量级的方式，尽管其他配置也可以工作。

WebRTC对象分配了偶数个端口。在初始检测单个WebRTC对象与一个数据通道，由WebRTC[p]在表2中，我们发现WebRTC对象分配一个（非多路）数据通道用不是一个而是两个UDP端口：一个交互式连接建立使用ICE/STUN协议和一个使用SCTP-over-DTLS数据传输。ICE/STUN不能在浏览器中禁用，因为它也用于验证通信同意（参见[41]中的4.2节），因此可以作为一种安全机制。因此，WebRTC对象不能单独分配端口，而只能成对地分配端口。

WebRTC数据通道和多路复用。（因为要实现UDP端口耗尽，首先创建本地webrtc对象，分配UDP偶数个端口（建立连接，数据传输），试图寻找在端口使用数量不变的情况下减少webrtc对象数量以防止高负载，禁用多路复用，效果明显）Chrome为每个WebRTC对象分配一个线程，这导致许多WebRTC对象的高负载。因此，我们寻找减少WebRTC对象创建数量，但能分配相同数量的UDP端口的方法。我们在表2中的测量结果记录了在同一个WebRTC对象中添加多个数据通道的效果，用WebRTC[u]表示。简单地添加数据通道并不会导致更多的端口分配，因为在默认情况下，所有数据通道都是在同一连接上多路复用的。

但是，对于WebRTC，可以禁用多路复用（减少受害者系统负载，增加攻击速度）。WebRTC编程接口的一个特性允许JavaScript在浏览器生成的SDP本地编辑SDP，然后将其提供给接收端。基于这一见解，我们做了两个修改：首先，我们通过从SDP中删除捆绑包=0选项[21]来禁用多路复用。其次，我们添加了数据通道具有它们自己的唯一标识符mid的副本（见图8）。我们用表2中的WebRTC[m]表示生成的WebRTC对象。

攻击概要。攻击者分配许多第一级WebRTC对象，直到错误消息指示超过进程限制为止。根据SDP的不同，每个WebRTC对象都会导致在第二级分配两个或更多个UDP端口号。使用站点隔离，攻击者可以通过在多个进程中重复攻击来扩大攻击，导致操作系统中短暂的UDP端口表的资源耗尽。

创新点。我们描述了通过浏览器api偷偷地阻塞许多UDP端口的新方法。我们的技术涉及（错误）使用WebRTC，使用数据流以避免检测，挂起连接以保持端口阻塞，以及环回连接以避免网络流量。通过咀嚼来禁用多路复用可以减少受害者系统的负载，同时增加攻击速度。

2.5. 资源耗尽攻击评估

我们评估了站点隔离对针对Windows和Linux的一级和二级资源耗尽攻击的影响。Windows 10（1909 build 18363.815），我们使用了两个流行的网络浏览器的发行版本，谷歌Chrome（83.0.4103.106）和微软Edge（83.0.478.45，基于Chromium），以及火狐的开发版本（Nightly 86.01a），实现了网站隔离称为项目裂变[12]的实验原型。对于Linux（Kubuntu 18.04.5 LTS），我们使用了Chrome（83.0.4103.106），这是Chrome的开源版本，和火狐（Nightly 86.01a）。Edge不适用于Linux，所以我们不得不将其排除在该平台之外。对这些结果的概述见表2。黄色单元格表示可以绕过有意的浏览器限制的设置。具有醒目的红单元格表示成功的攻击（分叉炸弹或UDP端口耗尽）。WebRTC[m]表示生成的WebRTC对象。

浏览器中的站点隔离资源分配及其不利后果。各列显示不同的浏览器、攻击变体（单个站点与多个站点）和站点隔离配置（关闭/打开）。行描述操作系统、资源类型和变量。进程的表格单元格显示了我们可以分配的最大进程数，以及一个指示是否观察到浏览器和/或操作系统崩溃的符号（cf.详情见附录C）。套接字的表格单元格描述了可以分配的UDP套接字的百分比。例如，在交换空间配置较小的Windows中，我们观察到带有站点隔离的Firefox访问多站点攻击时分配了457个进程，然后崩溃。另一个例子是，在带有Chrome的Windows中，WebRTC[m]可用于绕过浏览器对套接字分配的限制，即使是单站点攻击，但需要站点隔离和多站点攻击才能为DEMONS攻击分配足够的套接字。

2.5.1 分叉炸弹攻击

我们测量了当浏览器试图渲染iframe树时创建的进程的数量，直到浏览器崩溃，操作系统变得无响应，或者没有创建新的进程。Windows和Linux都可以将磁盘空间用作虚拟内存，这可能会改变可以在系统中创建的进程的数量。为了评估这一点，我们用“交换关”和“交换开”重复测量。Windows根据磁盘大小动态计算交换大小，因此我们包含了两种不同的磁盘配置。另一方面，Kubuntu Linux在默认情况下使用一个固定的1 GB交换分区。对于每一个组合（浏览器、操作系统、交换配置），测量重复5次，表2显示了创建的进程的中位数。

如果没有站点隔离，只创建了少量进程，我们无法为Windows或Linux上的任何测试浏览器超载浏览器或操作系统。启用了站点隔离，我们可以可靠地使浏览器（闪电）崩溃，甚至在超过一半的情况下，使操作系统不可使用(炸弹)（见附录C）。

2.5.2 UDP端口资源耗尽

Chrome和Edge在无站点隔离下：

Chrome在Windows和Linux上的测量结果是相同的。每个渲染器进程允许最多同时创建500个WebRTC对象。使用未注释的WebRTC[p]或WebRTC[u]对象，我们可以为每个WebRTC对象分配两个UDP端口，每个渲染器进程（窗口或选项卡）最多分配1000个UDP端口。使用一个被咀嚼的WebRTC[m]对象，我们绕过这个限制，并为每个渲染器进程分配多达3000个UDP端口。

Chrome和Edge在无站点隔离下：

由于我们能够为每个进程分配3000个端口，因此我们期望这个数字可以乘以基于站点的进程的数量。在Windows上，该策略成功地使用任何WebRTC对象变体（），在操作系统级别完全耗尽UDP短暂端口范围（最多一个开放端口）。在Linux上，我们还可以使用任何WebRTC变体超过UDP端口的浏览器分配限制，并分配大约8000个UDP端口（），而不是3000个（）。但是，此时浏览器进入了一个故障状态，在重新启动浏览器之前，不能分配更多的端口。

火狐浏览器与Chrome和Edge相比，火狐验证了咀嚼后的SDP，并发出了一条错误消息，拒绝了我们的两个修改。这意味着我们必须从我们对Firebox的评估中排除WebRTC[m]对象。至于WebRTC和UDP端口分配的总数，Firefox为所有浏览器进程中分配的全局UDP端口总数限制为1000个，无论站点隔离如何。因此，使用火狐，操作系统中的UDP端口不能耗尽（）。

2.6 高级攻击：基于过度滥用网络套接字的DNS中毒攻击

在web攻击者模型中，恶魔是针对客户端操作系统的DNS解析器的一种新型的缓存中毒攻击。魔鬼通过阻止除两个客户端UDP端口之外的所有客户端UDP端口，并通知投毒者这些打开的端口，从而禁用UDP端口随机化（见图2）。禁用UDP端口随机化是由Alharbi等人在[3]中引入的一个非特权恶意软件攻击者模型。表1总结了他们的工作和我们的工作之间的区别。

恶魔包括两个阶段。在设置阶段，通过二级资源耗尽（3.2,4.2）来禁用源端口随机化。在中毒阶段，恶意条目被注入到受害者的客户端操作系统的DNS解析器缓存中。只有第一阶段是新颖的，第二阶段类似于其他DNS缓存中毒攻击，如[3,24,35]。在这项工作中，我们只评估Windows 10作为一个客户端操作系统，并参考[3]来了解如何处理Linux和macOS中的差异。

架构

攻击者所需的基础设施由以下组件组成（请参见图3)： 1。Web服务器：Web服务器托管恶意网页，将交付到受害者的浏览器。 2.投毒者：一种系统，在接收到来自攻击者的web应用程序的信号后，向受害者发送大量随机选择的欺骗性DNS响应。多个投毒者也可以同时运行。 3.恶意服务器：将其IP地址插入到目标域下的受害者的DNS高速缓存中的系统。在攻击成功后，恶意服务器将自身模拟为良性目标服务器给受害者。

限制。恶魔要求攻击者通过欺骗伪造的DNS响应中的源IP地址来模拟一个良性的默认名称服务器。这对攻击者来说很容易实现，因为许多提供程序不过滤IP欺骗[33]。然而，私有IP地址是不可互联的，因此攻击者的投毒者相对于受害者的默认名称服务器的位置决定了恶魔的可行性。我们区分了三种情况：1。攻击者的投毒者和受害者的姓名服务器位于同一个本地网络中。 2.攻击者的投毒者和受害者的姓名服务器并不位于同一本地网络中。(a)受害者的名称服务器有一个公共IP地址。(b)受害者的名称服务器有一个私人的IP地址

IP欺骗在情况1和情况2的(a).中是可行的案例1是一个典型的公共网络场景；攻击者和受害者都使用相同的公共网络（例如，在咖啡馆、机场、图书馆、学校等）。案例2(a)发生在大型业务和云场景或家庭用户使用公名服务器的情况中。Case 2(b)是大多数家庭用户通过家庭路由器连接到互联网的默认设置。家庭路由器通常运行一个本地名称服务器，它通过DHCP发布给所有连接的设备。如果用户选择更改此默认行为，例如，为了防御[50]，或绕过提供者dns级过滤，他们就会转换到case 2(a)，并容易受到恶魔的攻击。

影响。恶魔允许攻击者控制操作系统中依赖于DNS安全的任何进程的网络通信。虽然今天大多数web应用程序依赖TLS来实现安全性，但并不是所有应用程序都是如此。例如，通过重新路由网络时间协议（NTP [36]），攻击者可以控制系统时间，这可能会影响证书验证或许可证管理。其他的例子是电子邮件协议，如SMTP [25]、IMAP [9]和POP3 [47]，以及文件传输协议FTP [39]，用于从固件更新到传输敏感业务文档的任何东西。虽然这些协议可以被TLS保护，但它们通常是完全不安全的。此外，一些软件存储库使用HTTP而不是HTTPS来自动下载[28]。在所有这些情况下，客户端DNS缓存中毒可以使攻击者访问对数据隐私和系统完整性的广泛攻击。

2.6.1 设置阶段

DNS中的源端口随机化依赖于自由的短暂的UDP端口。随着分配的UDP端口数量的增加，这个池会缩小并最终运行为空，有效地将DNS查询中的随机性减少到TXID提供的16位。但是，至少有一个UDP端口未分配，否则不能发送DNS查询，不可能中毒。因此，web攻击者在设置阶段的目标是强制浏览器分配除一个或少量已知的UDP短暂端口之外的所有端口。这需要两个步骤：

1.耗尽：攻击者通过创建足够数量的端口分配浏览器对象来分配（几乎）所有可用的端口，例如WebRTC连接。当错误消息指示资源耗尽时，或者当创建了这么多对象，当没有看到错误消息时，它们肯定会消耗操作系统中可用的最大临时端口数时，静默失败)，此过程将完成。 2.单一版本：攻击者破坏单个对象，从而将一个（或少量）端口释放回操作系统池中。攻击者必须能够确定与对象相关的端口号，可以直接与JavaScript关联，或者在远程连接的情况下，通过观察攻击者控制的远程端破坏

此时，操作系统有一个或几个可用的免费UDP源端口，攻击者知道它们的号码。如果端口号被攻击者在受害者的浏览器中读出，它们现在可以泄露给投毒者以准备中毒阶段，例如通过WebSocket或向攻击者的Web服务器发出的HTTP请求。如果在连接的远端观察到端口号，观察服务必须将它们泄漏给投毒者。见第小节A.1和第小节A.2，关于我们实施恶魔攻击的设置阶段的详细信息

现在，我们将详细描述如何使用基于站点隔离的操作系统资源耗尽攻击来实现恶魔攻击的有效设置阶段。攻击开始于受害者的web浏览器加载攻击者的网站，并执行包含的恶意JavaScript代码（见图4）。这个脚本执行两个任务：1。建立一个与投毒者进行双向通信的网络插座。这用于在安装阶段结束时泄漏可能的DNS查询端口。 2.通过“耗尽”和“单一发布”技术分配几乎所有短暂的UDP端口，使用大量的WebRTC对象(cf。第3.2小节）。

耗尽所有短暂的UDP源端口。结合咀嚼的WebRTC对象和站点隔离，攻击者可以分配足够的UDP端口来耗尽操作系统的整个UDP短暂端口池。在Windows 10下，有6个站点，每个站点创建一个具有多达1500个数据通道的WebRTC对象，就足以实现端口耗尽。安装阶段需要一段时间才能完成，这允许一个竞争条件，即一些UDP端口在安装阶段之前被分配，并在一些不相关的进程发布。为了防止这种情况，我们通过快速分配少量简单的WebRTC对象RTCn、RTCn-1、RTCn-2、...，来消耗两个端口。

正在释放两个UDP源端口。攻击者现在必须将至少一个UDP端口释放回操作系统池中。否则，嵌入在操作系统中的DNS解析器将不能发送更多的DNS查询，并且攻击将导致DoS，而不是成功的DNS缓存中毒。这就是攻击者在启动端口耗尽进程之前创建RTC0对象的原因。攻击者现在从RTC0中确定DTLS0(cf。)，并通过在设置阶段创建的WebSocket将端口号泄露给投毒者。最后，攻击者关闭RTC0，将STUN0和DTLS0释放回操作系统池。

免费端口的情况。如果操作系统在设置阶段开始时有奇数个空闲UDP短暂端口，那么耗尽阶段将不完整，因为攻击者可以使用WebRTC对象只分配偶数个的端口。因此，除了STUN0和DTLS0之外，还有一个端口LAST将未被分配。我们通过实验发现，大多数时候这是STUN0之前的端口，很可能是Windows中大多数顺序的UDP端口分配策略的产物。通常，攻击开始于未分配STUN0之前的端口的时间点，即LAST ：= STUN0−1。因此，投毒者必须考虑三个端口LAST，STUN0，DTLS0是否可能可供DNS解析器使用

正在查找DNS查询端口。在理想情况下，操作系统解析器只有一个可用的免费UDP临时端口，攻击者知道。然而，由于使用了WebRTC对象，在设置阶段之后，我们只剩下两个或三个可能的源端口，这取决于攻击之前的自由端口的数量（偶数或奇数）。为了使我们的成功率最大化，我们在中毒阶段将每个欺骗反应共发送三次，一次发送给DTLS0，STUN0 ：= DTLS0−1和LAST ：= DTLS0−2。因为发送到错误的源端口的数据包会被操作系统无声地丢弃，这种变化的唯一影响是，我们执行攻击的带宽是单一自由端口的三倍带宽。

2.6.2 投毒阶段

投毒者通过WebSocket从恶意的JavaScript代码接收泄露的DNS查询端口，并等待JavaScript代码即将通过嵌入到受害者操作系统中的DNS解析器触发对目标域的DNS查询的信号。然后投毒者进入中毒阶段（见图5），这与其他DNS缓存中毒攻击[3,24,35]类似。为了清晰和完整性，我们在这里包括了在攻击原型中实现和评估的中毒阶段的描述。

1.欺骗反应的爆发：在激活时，投毒者发送一连串的欺骗DNS反应。一个突发中的每一个这样的响应都有一个新的、随机选择的TXID，并将所选择的目标域解析为恶意服务器的IP地址。需要注意的是，第一个欺骗DNS响应到达的早，如在生成匹配的DNS查询之前，将被认为是主动请求的并被受害者的DNS解析器删除。这最大限度地增加了恶意反应首先到达的机会，而真实的反应永远不会被受害者处理。

2.触发DNS请求：一旦建立了欺骗响应流，攻击者就会迫使受害者发出在已经在传输中的欺骗响应的查询部分中与目标域匹配的查询。作为恶意网站的一部分，仍然在受害者的浏览器中运行的JavaScript会生成一个XMLHttp请求，例如bank.com。此请求的唯一目的是触发对目标域的DNS查询，浏览器必须在发送XMLHttpResust之前解决该查询。

从启动此查找的那一刻起，所有指向受害者的欺骗响应都可能有效，因为现在在欺骗DNS响应的查询部分中存在一个与目标域匹配的查询。唯一能阻止受害者接受潜在有效响应的剩余属性是一个不匹配的TXID。

3.DNS查询重传：在这一点上，了解受害者系统如何处理TXID不匹配是很重要的，因为攻击者不能期望立即猜出正确的TXID。根据[3]，我们在实验中观察到，不匹配的TXIDs的欺骗响应会立即触发DNS查询重传（见图5）。重传是一个重复发送到DNS服务器的DNS查询，以试图重试以前失败的DNS查找。对于单个DNS查询，此重传将重复多达四次，然后解析器将中止名称解析并出现错误。因为攻击者使用突发技术保持了稳定的欺骗响应流，所以每次重传尝试几乎都会立即得到欺骗响应，甚至在真实名称服务器接收重传之前。

4.阻止正确的DNS响应：在四次重传后，活动查询将无效，响应将不再被接受，即使它们的TXID与原始查询的ID相匹配。这包括良性服务器的答案，它也将被拒绝。尽管重传限制干扰了攻击者在短时间内使用大量txid的能力，但净效应是有利的，因为它很可能阻止真实名称服务器在客户机的缓存中放置正确的记录。

5.清洗和重复：为了获得更多的猜测，攻击者只需要重复中毒阶段，通过发送另一个欺骗的DNS响应突发，并在不久之后触发另一个DNS查询。一旦其中一个欺骗响应的TXID与受害者DNS查询中使用的ID匹配，攻击者就会观察恶意服务器上传入的XMLHttpRequst，从而结束中毒阶段。

2.7 DEMONS的评估

我们对恶魔进行了两次评估： (1)在互联网设置中，使用一个允许IP欺骗的托管服务，但也提供了一个不稳定的网络连接。这些结果说明了现实世界中的攻击者可能取得的成功率，他们可能也不得不应对这种不稳定的连接。(2)在一个封闭的实验室环境中。在这里，我们对网络进行了最优控制，我们的结果可以重现。为了进行比较，我们还使用了[3]所描述的无特权恶意软件攻击者的实验室环境，将恶魔攻击者的设置阶段替换为恶意软件攻击者的设置阶段，同时保留了实验的所有其他方面。表3总结了所有三个评估结果。

2.7.1 网络评估设置

攻击者设置。我们在莫斯科的一家允许IP欺骗的互联网托管提供商部署了恶魔基础设施（web服务器、毒者、恶意服务器，见图3）（2021年4月）。对于这些服务器，我们测量了上游带宽在1到200 MBit/s之间波动，平均延迟为70 ms（异常值高达200 ms），以及高达20%的数据包丢失的间歇性事件。虽然这些条件远非理想，但我们可以在这种情况下实施恶魔攻击，并具有显著的成功率。

我们让恶魔适应这些网络条件：为了补偿整体延迟，我们在发送给毒物的攻击开始信号和恶意触发的第一个XMLHttp请求之间插入了65 ms的延迟。延迟抖动和丢包丢失主要是通过将投毒者分布在三个不同的和服务器上来补偿的。此外，我们将突发大小从105个增加到850个欺骗DNS响应（每个突发总共有2550个DNS响应）。较长的爆发提高成功率，代价是攻击性能大幅下降。为了抵消这种性能损失，我们将每个突发的XMLHttp请求数量从1个增加到24个（总共120个DNS查询），两者之间有3个ms的延迟。

受害者设置。受害者机器是一个运行在桌面电脑2上的Windows 10 VM。受害者主机通过以太网电缆连接到一个家庭路由器上。互联网连接是一个终端用户的DSL连接，提供上游约27 Mbit/s和下游约80 Mbit/s。谷歌解析器（8.8.8.8）被配置为客户端操作系统中的默认DNS服务器。

隐匿性。在攻击期间，我们观察到受害者机器上的平均网络流量约为3-4 MBit/s。我们的受害者的互联网连接在攻击期间被正常使用，并且在典型的家庭办公室任务、浏览、电话和视频流媒体过程中没有显示出服务质量的任何下降。受害者不太可能注意到运行的恶魔攻击，除非网络流量被主动监控可疑活动。在中毒阶段，CPU负载远低于20%，只有在设置阶段，需要15秒，由于创建WebRTC对象造成的开销，CPU利用率才飙升到100%。

2.7.2 网络评估结果

表3总结了这两个恶魔实验的结果。在24小时的时间里，我们总共进行了恶魔351次实验。我们记录了131例（37%）成功的DNS缓存中毒事件。实验失败了219次（62%），因为真实的DNS服务器在被毒者失效之前响应了DNS查询。该实验被中止了一次，因为它在达到2000次爆发的极限之前没有产生一个结果。

2.7.3实验室评估的设置，

我们使用了三台戴尔Optiplex 9603台式计算机通过gb-以太网交换机4连接。第一台电脑扮演了受害者的角色，在Windows 105的股票安装上运行谷歌Chrome。第二个系统充当良性的DNS服务器。第三个系统被配置为一个路由器，模拟受害者和攻击者的ISP和良性DNS服务器之间的基础设施。

一个Thinkpad 2 Oracle虚拟盒6 VM，4核，8 GiB内存，英特尔酷睿i7 3770k，32 GiB内存主机。3英特尔酷睿2四Q9400,4 GiB内存，英特尔82567LM-3千兆网卡4D-链接DGS-108千兆以太网交换机5 Chrome 83.0.4103.106 onws10（1909构建18363.815）t480运行攻击者的网络服务器，投毒者和一个脚本监测和记录实验结果。为了模拟真实的网络条件，我们使用流量控制将延迟设置为1 ms，并将攻击者的带宽限制为最大20 Mbit/s。由于实验室设置提供了一个比互联网设置更一致的连接，我们只使用了一个投毒者和一个更小的525个响应。

2.7.4

实验室评估结果在实验室设置的总共133次实验中，恶魔攻击成功48次（36%），失败85次（64%）。为了比较web攻击者模型中的恶魔和[3]中描述的恶意软件攻击者，我们用Python实现了一个协作的、无特权的恶意软件攻击者。恶意软件的安装阶段只是分配系统中除一个之外的所有UDP套接字，其中一个，并将剩余的端口通过网络泄露给攻击者（见表1）。我们在恶魔实验室评估中替代受害者浏览器，保持网络配置和攻击者的所有其他方面相同。在实验室设置的总共125次实验中，恶意软件攻击成功了71次（57%），失败了54次（43%）。

2.7.5

讨论比较恶魔和恶意软件攻击者，我们发现，由于安装阶段更快，恶意软件攻击者的最小攻击持续时间更短。由于在浏览器中创建WebRTC对象相对较慢，恶魔设置阶段有更多的开销。尽管设置阶段更快，但恶意软件攻击者比恶意软件攻击者的平均和最大攻击持续时间更长，因为恶意软件攻击者可以维持更长时间的中毒阶段。这导致恶意软件攻击者更高的总运行时间和更高的总体成功率。总的来说，恶魔攻击者的成功率比恶意软件攻击者低21%。我们怀疑，这部分原因是由于与用Python编写的恶意软件攻击者相比，从JavaScript触发的DNS查询的时间抖动，部分原因是由于运行浏览器本身导致了系统中额外的DNS和其他活动。我们注意到，在我们的实验设置中，当良性DNS反应被受害者接受一次时，我们将中毒尝试视为失败。相比之下，[3]的评估是基于一个DNS条目（TTL）为30秒的生存时间，以及一个攻击者在此时间之后重试攻击，从而获得几乎完美的总体成功率。我们对良性DNS反应所使用的TTL没有这样的假设。

2.8缓解措施

2.8.1 缓解分叉炸弹攻击

谷歌Chrome团队没有认为叉子炸弹攻击是一个安全漏洞，也没有实施任何对策。这使得所有基于Chrome的浏览器都容易受到基于站点隔离的攻击，比如分叉炸弹。在本节中，我们将就如何改进现场隔离以防止叉形炸弹袭击提出一些建议。

应用操作系统资源限制。在Linux上，cgroups可以用于限制操作系统中单个应用程序的可用资源——例如web浏览器——（其他系统也提供类似的功能）。因此，通过限制启用了站点隔离的浏览器可用的进程数量，我们可以防止DoS攻击操作系统。然而，与此同时，DoS对浏览器本身的攻击将变得更容易——cgroups分配的限制可以通过多个标签耗尽，也可以通过单个标签耗尽，就像基于站点隔离的分叉炸弹攻击一样。

针对IP地址的浏览器进程整合。在“站点隔离”中，进程整合[40,4.1.1节]用于减少进程的总数：如果两个选项卡在两个不同的iframe中包含同一个站点，则该站点只启动一个进程。浏览器也可以将进程整合应用于IPv6地址块，这样一个块的所有IP地址都作为单个原点。然而，如果这些块太大，它们可以用来规避网站隔离——如果一个攻击者试图租一个IP地址在同一地址块作为一个IP地址用于访问一个目标网站，他们可能会访问目标网站的过程在受害者的浏览器。

2.8.2我们的解决方案是：通过可见的窗口和标签来限制进程

我们在浏览器中实现并评估了以下针对分叉炸弹攻击的对策：每个窗口/选项卡都被分配了一个进程的限制L。每次用户打开一个新的窗口/选项卡wi时，浏览器就会初始化一个本地限制Li ：= L，并在一个变量Ci中跟踪wi资源的使用情况。只要是Ci≤Li，页面加载就会正常进行。如果达到最大进程数Li，浏览器会通过警告消息中断页面处理，使用户的Li增加某个固定值∆L。我们的解决方案不需要特殊的操作系统接口。

我们评估了Tranco6 [27] Top 1000个网页，并测量了为每个这些页面创建的进程的数量。我们发现，从这个集合中，单个页面创建的最大进程数量是19个。包括一些额外的净空间，我们设置了L = 30。有了这个限制，攻击者必须打开至少7个选项卡来触发浏览器崩溃，以及至少10个选项卡来使操作系统不可使用（表2）。

我们在Chrome101.0.4951.647中实现了所描述的修改。生成的补丁可以作为我们的工件1的一部分获得，并提交给了Chrome和火狐的开发人员

对于一个额外的假阳性评估，我们根据为每个网站创建的进程的数量对Tranco Top 1000进行了排序。在50个选项卡中打开重新排序列表中的前50个网页，将导致在操作系统中运行171个进程，这远低于我们在表2中确定的DoS攻击的阈值。

为了验证我们的补丁所引入的变化不会对浏览器的性能产生明显的影响，我们使用集成到铬中的分析工具记录了Tranco Top 5网站的页面加载时间。我们没有发现显著差异。

我们还验证了我们的补丁的有效性，通过打开Tranco Top 50页面和我们的网站隔离叉-炸弹攻击页面的Chrome网站隔离-补丁。在创建了30个站点后，攻击页面被中断，Chrome站点隔离补丁和操作系统（Kubuntu 18.04 LTS）都保持稳定。用一个未打补丁的Chrome重复这个实验会导致操作系统冻结。与我们的恶意攻击者网站相比，没有一个良性网站触发了站点隔离-进程-限制对话框。这表明我们的补丁不太可能以错误的阳性警告来影响用户体验。

2.8.3 减轻UDP端口的损耗

谷歌浏览器谷歌Chrome团队认为恶魔是一个安全漏洞。由于恶魔是一种复杂的攻击，很容易通过消除成功的先决条件来减轻。在Chrome中，开发人员在整个浏览器实例中实现了6000个UDP套接字。我们用这个对策重新评估了Chrome，并确认这个限制现在已经有效地执行了（详细结果见附录中的表2）。这与基于chromium的浏览器和火狐的行为相一致，火狐已经有一个全球限制为1000个端口。我们注意到，对于这两种浏览器，全局限制都足够高，可以显著减少DNS查询的可用短暂端口的数量，从而降低了源端口随机化作为卡明斯基攻击对策的有效性。

在操作系统中重新设计网络套接字。使用UDP端口外的DNS缓存中毒攻击的根本原因是，临时端口池必须在所有IP地址之间共享。然而，在关于源端口随机化的有效性的计算中，通常假设每个目标IP地址的全部可用的短暂UDP源端口将是可用的[24,35,45]。抽象网络套接字和通过Berkely套接字API创建的实际操作系统套接字之间的不匹配创建了一个攻击面，使用UDP的不相关的子系统可以相互干扰。不幸的是，更改套接字API将需要完全重新设计网络堆栈并在应用程序中的使用。

2.8.4 DNS缓存中毒攻击缓解

可以通过使用DoH来减轻，但仅适用于那些运行在使用DoH的浏览器中的web应用程序。使用DoH的浏览器仍然可以作为攻击向量，使用本文所描述的技术来阻塞操作系统的UDP端口。因此，对于依赖于经典DNS的应用程序，仍然可以禁用源端口随机化。然而，对于一个完整的攻击设置，攻击者现在必须控制两个应用程序：一个用于阻止UDP端口和释放单个端口（例如，浏览器），另一个用于发送一个应该有毒的DNS请求。一个更大的障碍是对卫生部的有限支持。目前，只有Mozilla在默认配置中支持DoH，而且只在某些国家支持。我们测试的浏览器没有在默认配置中使用DoH。此外，最近还发现了[22]从卫生部到经典的DNS-over-UDP的降级攻击。

其他解决方案。作为一种减轻DNS缓存中毒的直接方法，DNS TXID的大小可以被扩展，使源端口随机化无关紧要。然而，目前还没有知道这方面的标准化活动。这可能是由于部署DNSSEC [1,4]已经有24年的困难。DNSSEC将解决这个问题，但只有当所有域都使用DNSSEC，或者当应用程序可以确定哪些域是安全的，哪些域不安全时，才能实现完全的缓解。此外，操作系统解析器将必须验证DNSSEC签名链。