MIT 6.858 计算机系统安全讲义 2014 秋季（二）（2）-阿里云开发者社区

MIT 6.858 计算机系统安全讲义 2014 秋季（二）（1）https://developer.aliyun.com/article/1484149

SGX 和 Haven

为什么我们要阅读这篇论文？**待办事项：**哪篇论文？SGX 还是 Haven？

先进的硬件隔离机制

我们对隔离机制的巡回的最后一篇论文

在实践中相关的强大威胁模型

许多桌面电脑运行恶意软件
恶意软件可能控制整个操作系统

使用尖端技术（英特尔 SGX）

但是，对于 SGX 尚无部署经验
可能存在设计和实现缺陷
第一批硬件已经推出（参见下面的参考资料）

SGX 目标

即使操作系统被入侵，应用程序仍然可以保持秘密

也许不是整个操作系统被入侵
但也许攻击者正在运行键盘记录器

目标应用程序：

登录到您的银行

安全：操作系统/键盘记录器无法窃取您的密码+PIN 以登录

用于受版权保护内容的视频/音乐播放器（DRM）

安全：操作系统无法窃取解密内容的密钥

雄心勃勃的目标：

应用程序依赖于操作系统

如何防御恶意操作系统？

操作系统接口很广

如何检查应用程序是否操作系统行为适当？

“Iago”攻击的机会很多

查看论文"Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface" 这里或我们的首页。

Iago 攻击：不受信任的操作系统可以用来攻击应用程序的攻击

操作系统修改getpid()和time()以返回不同的数字，相同的数字

getpid()和time()经常用于生成伪随机数

操作系统可能混淆运行 SSL 的服务器

操作系统可以记录成功连接的数据包
操作系统可能导致 SSL 的下一个实例使用相同的服务器随机数

通过为time()和getpid()返回与早期连接相同的值

操作系统可以重放数据包

SSL 服务器认为这是一个新连接，但实际上不是
可能发起中间人攻击

操作系统修改mmap()以映射一个由操作系统控制的物理页面到应用程序堆栈上

malloc()调用mmap()
操作系统可以运行任意代码
操作系统可以读取应用程序的秘密（例如 SSL 连接的私钥）

**教训：**简单的系统调用（例如，getpid 和 time）可能会引起问题

应用程序必须以防御性方式编写
防止遗留应用程序受恶意操作系统攻击似乎很困难

针对恶意操作系统的防御研究很多

一些使用 TPM 或延迟启动
一些使用受信任的虚拟化程序
一些使用特殊处理器
影响不大—主要是一项具有挑战性的智力活动
现在英特尔的 Skylake 包括SGX（参见下面的参考资料）

它提供硬件机制来帮助防御 Iago 攻击

SGX 威胁模型

攻击者控制操作系统
攻击者可以观察处理器和内存之间的流量

除了处理器之外的每个组件都是不受信任的

英特尔是可信任的

芯片正常工作
私钥没有泄露

侧信道无法被利用

SGX：软件保护扩展

**飞地：**进程内的受信任执行环境

处理器确保飞地内存对操作系统、BIOS 等不可访问

证明

处理器使用内置于芯片中的私钥对飞地内容进行签名
验证器使用英特尔的公钥来检查签名

密封

在终止时对飞地进行密封和稍后解封的方案
待办事项： 他们是否指的是类似于“分页”或停止，保存到磁盘，然后恢复并继续运行的操作？

飞地

Haven 论文中的图 1
ECREATE创建一个空飞地

起始虚拟地址和大小

EPC：飞地页面缓存

物理内存中的区域
处理器的内存加密接口

写入/读取到/从 EPC 时进行加密/解密
也受完整性保护

EADD用于向飞地添加 EPC 页面

处理器维护一个映射（EPCM），对于每个 EPC 页面记录：

页面类型（REG，…），飞地 ID，页面的虚拟地址和权限
EPCM 仅对处理器可访问
在每次飞地页面访问时，都要查阅地图

页面是否处于飞地模式？
页面是否属于飞地？
页面是否为访问的虚拟地址？
访问是否符合页面权限？

将 EPC 页面分页到外部存储

操作系统执行EWD将页面驱逐到缓冲区

加密，版本号等。

操作系统可以将缓冲区写入外部存储
操作系统执行ELDB将加密页面加载到 EPC 中

使用版本号检测回滚攻击

起始飞地（EXTEND，EINIT）：

处理器保留了飞地构建方式的加密日志 _ EXTEND将 256 字节区域添加到日志
日志包含内容（代码，数据，堆栈，堆），每个页面的位置，安全标志
EINIT以SIGSTRUCT作为参数

由密封机构（飞地编写者）签名
包括：飞地的预期签名哈希和飞地所有者的公钥
EINIT验证签名和哈希
飞地身份存储在SECS中

证明： 远程方可以验证飞地是否运行正确的代码

飞地使用EGETKEY获取其密钥

用于加密和密封的密钥

EREPORT生成一个签名报告

报告包含日志的哈希和飞地的公钥

公共数据是否在报告中由飞地提供？

此报告可以传达给另一个飞地
接收飞地可以使用飞地中的公钥验证报告

特殊的报价飞地可以使用处理器的私钥创建一个签名的“报价”

使用组签名密钥，以便无法识别个体处理器

进入/退出飞地：

使用 ENTER 和线程控制结构（TCS）进入
退出：EEXIT，中断或异常
使用 ERESUME 恢复飞地

受保护的银行客户端（假设和简化）

目标： 防止操作系统窃取用户的密码
假设从键盘到飞地有一个安全路径（Intel ME？）
客户端下载银行应用程序并运行
银行应用程序创建带有代码+数据的飞地

代码包括从键盘读取，SSL 等。
生成一个报价
连接到服务器，建立安全通道（例如 SSL），并发送报价

服务器验证报价

服务器知道客户端启动的软件是否正确
即不是某个可能将用户密码通过电子邮件发送给对手的恶意客户端

服务器发送挑战

客户端使用密码通过 SSL 响应挑战
飞地内的密码，加密
操作系统无法窃取

服务器检查挑战

SGX 安全讨论

评估安全性困难

带有 SGX 的处理器刚刚可用
没有部署经验

处理器
处理器的制造
英特尔的私钥

伊阿戈攻击

操作系统能在 enclave 内部读写数据吗？

处理器的 EPC 阻止了这一点

操作系统能重新映射内存吗？

处理器的 EPCM 防止此攻击

操作系统能混淆应用程序吗？

客户端必须小心编写，依赖于少量操作系统功能
客户端需要可靠的随机源来实现 SSL

RDRAND

客户端必须能够发送和接收数据包

检查结果

侧信道攻击

威胁模型排除了，但在实践中可能存在
超线程
共享 L3 缓存
多插槽

Haven

使用 SGX 在云中安全地执行未修改的 Windows 应用程序
安全地意味着不信任云提供商
Haven 是一个研究项目

威胁模型

系统管理员控制云软件
远程攻击者可能控制云软件
操作系统可能发起“伊阿戈”攻击

可能向 Haven 传递任意值
可能中断 Haven 的执行

硬件实现正确

SGX 是正确的

计划：受保护的执行

在云中运行应用程序，其安全性相当于在自己的硬件上运行应用程序

不信任云软件

提供一个应用程序环境，使其能够与不受信任的软件交互

应用程序需要发送数据包
应用程序需要存储文件
…
应用程序需要操作系统

挑战

如何在主机操作系统之上实现操作系统，同时仍然能够抵抗伊阿戈攻击

Haven 建立在两个组件之上

英特尔 SGX
Drawbridge

在 libOS 实现 Win32 的顶部提供一个小接口
小接口保护主机操作系统免受应用程序影响（类似于本机客户端）
Haven 保护应用程序免受主机操作系统的影响

Haven 设计（图 2）

实现 Drawbridge 的 API，以防范伊阿戈攻击
Shield 模块在 enclave 内部实现 API

使用窄、不受信任的 API 与主机操作系统交互
不受信任的 API 是 drawbridge API 的子集（见图 3）

在 Shield 和主机内核之间的不受信任的运行时隧道

启动时也需要

主机内核包含 SGX 驱动程序和 drawbridge 主机

drawbridge 主机使用 OS 调用实现窄 API

Shield 服务

虚拟内存

enclave 从 0 开始（处理应用程序、libos 的空指针引用）
跟踪应用程序/libos 使用的内存页面
从 enclave 中添加/删除内存页面

验证更改是否正确

从不允许主机选择虚拟内存地址
不允许应用程序和 libos 在 enclave 外部分配页面

存储

最终实验室

线程

用户级调度（例如，以便互斥量起作用）
在启动时将线程复用到固定数量的线程上

在开始时分配固定数量的 TCS

杂项

用于可信随机源的 RDRAND
没有 fork
没有地址空间随机化

讨论

Haven 能运行未修改的应用程序吗？

没有 fork–Windows 上的小问题？
不能将 enclave 页面映射到多个虚拟地址

需要修改应用程序

安全性？

对不受信任接口进行模糊测试？

参考资料

网络安全

注意： 这些讲座笔记是从 2014 年课程网站上稍作修改的。

什么是网络？

在旧时代，它是一个简单的客户端/服务器架构（客户端是您的 Web 浏览器，服务器是网络上的一台机器，可以向您的浏览器提供静态文本和图像）。

在旧时代，服务器端比客户端复杂得多：浏览器不支持丰富的交互性，但服务器可能与数据库，其他服务器等进行接口。
因为服务器非常复杂，“网络安全”侧重于服务器端。到目前为止，这门课程主要也侧重于服务器端（例如，Web 服务器上的缓冲区溢出，OKWS 服务器中的权限分离）。

现在网络已经改变：现在浏览器非常复杂。

JavaScript：允许页面执行客户端代码。
DOM 模型：提供页面的 HTML 的 JavaScript 接口，允许页面添加/删除标签，更改它们的样式等。
XMLHttpRequests（AJAX）：异步 HTTP 请求。
Web 套接字：全双工客户端-服务器通信通过 TCP。
Web 工作者：多线程支持。
多媒体支持：<video>，网络摄像头，屏幕共享。
地理位置信息：浏览器可以通过检查 GPS 单元来确定您的位置。Firefox 还可以通过将您的 WiFi 信息传递给 Google 位置服务来定位您。
<canvas>和 WebGL：位图处理和交互式 2D/3D 图形。
原生客户端（NaCl）：允许浏览器运行本机代码！

现在网络是一个用于分布式计算的复杂平台！但这对安全性意味着什么？

威胁面非常广！

它超过 9000 了！

单个 Web 应用程序现在跨越多种编程语言，操作系统，硬件平台。我可能在 Windows 上运行 Firefox，与运行 Apache 并与 memcached 和 MySQL 进行交互的 Linux 服务器进行交互）。
所有这些组合使得验证端到端的正确性变得困难，甚至理解系统在做什么也变得困难。例如：解析上下文和内容消毒。

<script> var x = 'UNTRUSTED'; </script>
//Single quote breaks out of JS string
//context into JS context
//
//"</script>" breaks out of JS context
//into HTML context

网络规范非常长，非常复杂，偶尔矛盾，并且不断发展。

因此，浏览器供应商会做一些与规范大致相似的事情，然后和朋友们一起开玩笑。
如果你想了解恐怖，可以去QuirksMode

客户端 Web 应用程序

在本讲座中，我们将专注于 Web 应用程序的客户端。特别是，我们将专注于如何隔离来自不同提供者的内容，这些内容必须存在于同一个浏览器中。

Web 应用程序和传统桌面应用程序之间有很大的区别：桌面应用程序中的位通常来自单个供应商（例如，Microsoft 或 Apple 或 TurboTax），但单个 Web 应用程序包含来自许多不同主体的内容！

http://foo.com/index.html
+--------------------------------------------+
|  +--------------------------------------+  |
|  |        ad.gif from ads.com           |  |
|  +--------------------------------------+  |
|  +-----------------+ +------------------+  |
|  | Analytics .js   | | jQuery.js from   |  |
|  | from google.com | | from cdn.foo.com |  |
|  +-----------------+ +------------------+  |
|                                            |
|        HTML (text inputs, buttons)         |
|                                            |
|  +--------------------------------------+  |
|  | Inline .js from foo.com (defines     |  |
|  | event handlers for HTML GUI inputs)  |  |
|  +--------------------------------------+  |
|+------------------------------------------+|
|| frame: https://facebook.com/likeThis.html||
||                                          ||
|| +----------------------+ +--------------+||
|| | Inline .js from      | | f.jpg from https://
|| | https://facebook.com | | facebook.com |||
|| +----------------------+ +--------------+||
||                                          ||
|+------------------------------------------+|
|                                            |

问题：哪些 JavaScript 代码可以访问哪些状态？例如…

来自 google.com 的分析代码能否访问来自 cdn.foo.com 的 jQuery 代码中的状态？[似乎可能不好，因为不同的负责人编写了代码，但它们包含在同一个框架中…]

是的，它们可以！它们将获得相同的起源。

来自 cdn.foo.com 的 jQuery 代码能否访问由 foo.com 定义的内联 JavaScript 代码中的状态？[它们几乎来自同一个地方…]

是的，它们可以。它们具有相同的起源。

分析代码或 jQuery 能够访问 HTML 文本输入吗？[我们必须以某种方式使内容交互。]

是的，包含在框架中的 JS 代码可以与框架的 DOM 交互。

Facebook 框架中的 JavaScript 能否触及 foo.com 框架中的任何状态？Facebook 框架是 https://，但 foo.com 框架是常规的 http://，这有关系吗？

只能使用 postMessage 与其通信
不能向 foo.com 发出 AJAX 请求
不能对框架执行任何操作

要回答这些问题，浏览器使用一种称为同源策略的安全模型。

同源策略

模糊的目标： 两个不同的网站不应该能够篡改彼此的内容。
易于陈述，但难以实现。

显然不好：如果我打开两个不同的网站，第一个网站不应该能够覆盖第二个网站的视觉显示。
显然好：开发人员应该能够创建结合来自相互合作的网站的内容的混搭网站。

例如：一个将 Google 地图数据与房地产数据结合的网站。
例如：广告。
例如：社交媒体小部件（例如 Facebook 的“赞”按钮）。

难以说：如果来自 Web 服务器 X 的页面从不同服务器 Y 下载 JavaScript 库，那么该脚本应该具有什么功能？

同源策略的基本策略： 浏览器为页面中的每个资源分配一个起源，包括 JavaScript 库。JavaScript 代码只能访问属于其起源的资源。
一个起源的定义：scheme + hostname + port

例如：

http://foo.com/index.html（http，foo.com，80 [隐式]）
https://foo.com/index.html（https，foo.com，443 [隐式]）
http://bar.com:8181/index.html（http，bar.com，8181）

方案可以是 http, https, ftp, file 等。

四个主要思想：

每个起源都与客户端资源相关联（例如 cookies、DOM 存储、JavaScript 命名空间、DOM 树、窗口、视觉显示区域、网络地址）。

一个起源在 Unix 世界中是 UID 的道德等价物。

每个框架都获得其 URL 的起源。

一个框架在 Unix 中是一个进程的道德等价物。

由框架包含的脚本以该 HTML 文件起源的权限执行。这对内联脚本和从外部域拉取的脚本都是正确的！

Unix 类比：运行存储在别人家目录中的二进制文件。

被动内容（例如图片和 CSS）不能执行代码，因此此内容被赋予零权限。

回到我们的例子：

Google 分析脚本和 jQuery 脚本可以访问属于 foo.com 的所有资源（例如，它们可以读取和写入 cookie，附加事件处理程序到按钮，操作 DOM 树，访问 JavaScript 变量等）。
Facebook 框架中的 JavaScript 代码无法访问 foo.com 框架中的资源，因为这两个框架具有不同的来源。这两个框架只能通过 postMessage()进行通信，这是一个允许域交换不可变字符串的 JavaScript API。

如果两个框架在相同的来源中，它们可以使用 window.parent 和 window.frames[]直接与彼此的 JavaScript 状态交互！

Facebook 框架中的 JavaScript 代码不能向 foo.com 的服务器发出 XMLHttpRequest [网络是一个具有来源的资源！] …
… 然而，Facebook 框架可以从 foo.com 导入脚本、CSS 或图像（尽管该内容只能更新 Facebook 框架，因为内容继承了 Facebook 来源的权限，而不是 foo.com 来源）。
浏览器检查 ad.gif 的类型，确定 ad.gif 是一个图像，并得出结论该图像根本不应具有任何权限。

如果浏览器错误地识别对象的 MIME 类型会发生什么？

旧版本的 IE 曾经进行 MIME 嗅探。

目标：检测当 web 服务器给对象分配了错误的文件扩展名时（例如，foo.jpg 实际上应该是 foo.html）。
机制：IE 查看文件的前 256 个字节，并查找指示文件类型的魔术值。如果魔术值与文件扩展名不一致，IE 会信任文件扩展名。
问题：假设一个页面包含来自受攻击者控制的域的一些被动内容（例如，一个图像）。受害页面认为安全导入被动内容，但攻击者可以故意在图像中放入 HTML+JavaScript 并在受害页面中执行代码！

结论：浏览器是复杂的—添加一个出于善意的功能可能会导致微妙且意想不到的安全漏洞。

让我们更深入地了解浏览器如何保护各种资源。

框架/窗口对象

注意：框架对象是 HTMLIFrameElement 类型的 DOM 节点，而 window 对象是全局 JavaScript 命名空间的别名。

两个对象相互引用。

获取它们框架 URL 的来源-或-获取**调整后的document.domain**的来源

一个框架的document.domain最初是从 URL 中正常派生的。
一个框架可以将document.domain设置为完整域的后缀。例如：

x.y.z.com // 原始值
y.z.com // 允许的新值
z.com // 允许的新值
a.y.z.com // 不允许
.com // 不允许

浏览器区分已写入的document.domain和未写入的document.domain，即使两者的值相同！
两个框架可以相互访问，如果：

他们都将document.domain设置为相同的值，或者
两者都没有更改document.domain（并且这些值在两个框架中是相等的）

这些规则有助于保护网站免受由有缺陷/恶意子域名攻击的风险，例如，x.y.z.com试图通过缩短其document.domain来攻击y.z.com。

DOM 节点

获取其周围框架的来源

Cookies

一个 cookie有一个域和一个路径。例如：*.mit.edu/6.858/

域名只能是页面当前域名的（可能是完整的）后缀。
路径可以是“/”，表示该域中的所有路径都可以访问该 cookie。

设置 cookie 的人可以指定域和路径。

可以通过服务器使用标头设置，也可以通过写入document.cookie的 JavaScript 代码设置。
"secure"标志也可以表示仅限 HTTPS 的 cookie。

浏览器将 cookie 保存在客户端磁盘上（除了 cookie 过期、临时 cookie 等）。
在生成 HTTP 请求时，浏览器会在请求中发送所有匹配的 cookie。

仅为 HTTPS 请求发送安全 cookie。

JavaScript 代码可以访问与代码来源匹配的任何 cookie，但请注意，cookie 的路径和来源的端口将被忽略！

协议很重要，因为 HTTP JavaScript 无法访问 HTTPS cookie（尽管 HTTPS JavaScript 可以访问两种类型的 cookie）。
*注意：*还有http-only cookies，JS 代码无法直接访问。这些 cookie 只会随着匹配的 HTTP 请求由浏览器发送。

**问：**为什么重要保护 cookie 免受任意覆写？
**A：**如果攻击者控制了一个 cookie，攻击者可以强制用户使用受攻击者控制的帐户！

例如：通过控制 Gmail 的 cookie，攻击者可以重定向用户到一个受攻击者控制的帐户，并读取从该帐户发送的任何电子邮件。

**问：**foo.co.uk 设置 cookie 的域为 co.uk 有效吗？
**A：**根据我们迄今讨论的规则，这是有效的，但实际上，我们应该禁止这样做，因为“.co.uk”在语义上类似于“.com”这样的单一“原子”域。

Mozilla 维护一个公共列表，允许浏览器确定顶级域的适当后缀规则。请参阅PublicSuffix。

HTTP 响应：对同源策略有许多例外和半例外

XMLHttpRequests：默认情况下，JavaScript 只能向其来源服务器发送 XMLHttpRequests…除非远程服务器启用了跨域资源共享（CORS）。该方案定义了一些新的 HTTP 响应头：

Access-Control-Allow-Origin 指定哪些来源可以查看 HTTP 响应。
Access-Control-Allow-Credentials 指定浏览器是否应接受来自外部来源的 HTTP 请求中的 cookie。

**图片：**一个框架可以从任何来源加载图像

… 但它不能查看图像像素…
… 但它可以确定图像的大小。

**CSS：**与图像类似–一个框架不能直接读取外部 CSS 文件的内容，但可以推断出一些属性。
JavaScript：一个框架可以从任何来源加载 JavaScript，但它不能直接检查<script>标签/XMLHttpRequest 响应主体中的源代码，但所有 JavaScript 函数都有一个公共的toString()方法，可以显示源代码，页面的主服务器始终可以直接获取源代码然后传递给页面！

为了防止逆向工程，许多网站都会对其 JavaScript 进行缩小和混淆。

插件：一个框架可以运行来自任何来源的插件。

例子：

<embed src=...> //Requires plugin-specific  
                //elaborations.

跨站点请求伪造攻击

请记住，当浏览器生成 HTTP 请求时，它会自动包含相关的 cookie。

如果攻击者让用户点击这样的 URL 会发生什么？* http://bank.com/xfer?amount=500&to=attacker

这种攻击被称为跨站点请求伪造（CSRF）。

解决方案：在 URL 中包含一些对攻击者难以猜测的随机数据。例如：

<form action="/transfer.cgi" ...>
    <input type="hidden"
           name="csrfToken"
           value="a6dbe323..."/>

每当用户请求页面时，服务器都会生成带有新随机令牌的 HTML。当用户提交请求时，服务器会在实际处理请求之前验证令牌。
缺点：如果指向同一对象的每个 URL 都是唯一的，那么缓存该对象就会变得困难！

DNS 重绑定攻击

网络地址几乎都有一个来源。

一个框架可以向与其来源匹配的主机+端口发送 HTTP 和 HTTPS 请求。
注意，同源策略的安全性取决于DNS 基础设施的完整性！
DNS 重绑定攻击

目标： 攻击者希望以他不控制的来源（victim.com）的权限运行受攻击者控制的 JavaScript 代码。
方法：

攻击者注册一个域名（例如，attacker.com）并创建一个 DNS 服务器来响应相关查询。
用户访问 attacker.com 网站，例如，通过点击广告。
攻击者网站希望下载一个对象，但首先，浏览器必须为 attacker.com 发出 DNS 请求。攻击者的 DNS 服务器会响应一个指向攻击者 IP 地址的 DNS 记录。然而，记录的生存时间很短。
攻击者将 attacker.com 重新绑定到 victim.com 的 IP 地址。
一会儿，攻击者网站创建一个连接到 attacker.com 的 XMLHttpRequest。该请求实际上将被发送到 victim.com 的 IP 地址！ 浏览器不会抱怨，因为它会重新验证 DNS 记录并看到新的绑定。
好吧，但是请求将不会携带正确的 cookie 给 victim.com，因为浏览器仍然认为它们正在与 attacker.com 交互，对吧？
那么 HTTP 请求中的Host:头部不会指示 attacker.com 吗，所以 victim.com 的 web 服务器可以拒绝请求。
攻击者页面现在可以窃取数据，例如，使用 CORS XMLHttpRequest 发送到攻击者域。

解决方案：

修改 DNS 解析器，使外部主机名永远不能解析为内部 IP 地址。
浏览器可以固定 DNS 绑定，而不考虑其 TTL 设置。但是，这可能会破坏使用动态 DNS（例如，用于负载平衡）的 Web 应用程序。

屏幕上的像素怎么办？

它们没有来源！框架可以在其边界框内的任何地方绘制。
问题：父框架可以在其子框架的像素上方叠加内容。

例如：攻击者创建了一个页面，上面有一个诱人的按钮，如“点击这里领取免费 iPad！”在该按钮上方，页面创建了一个包含 Facebook“赞”按钮的子框架。攻击者将该按钮放在“免费 iPad”按钮上方，但使其透明！因此，如果用户点击“免费 iPad”按钮，实际上会在 Facebook 上“赞”攻击者的页面。

解决方案

**防框架代码：**包含阻止您的页面被包含为框架的 JavaScript：

if(top != self)

让你的网络服务器发送X-Frame-Options HTTP 响应头。这将指示浏览器不将您的内容放在子框架中。

那些没有来源的框架 URL 怎么办？*例如：+ file://foo.txt + about:blank + javascript:document.cookie=“x” *有时框架只能被具有该协议的其他框架访问（例如，file://）。[如果您正在调试一个站点并且想要混合使用 file://和 http://内容，这可能会很烦人]。*有时框架对所有其他来源都是不可访问的（例如，“about:”）。*有时来源是从创建 URL 的人那里继承的（例如，“javascript:”）。这可以防止攻击者.com 创建属于 victim.com 的框架，然后将 victim 框架导航到 javascript: URL–我们不希望 JavaScript 在 victim.com 的上下文中执行！

DNS 名称可以被用作攻击向量

IDN：国际化域名（非拉丁字母）。
支持更多语言是好事，但现在，用户很难区分两个域名。

例如：西里尔字母“C”字符看起来像拉丁字母“C”字符！因此，攻击者可以购买一个类似于“cats.com”的域名（带有西里尔字母“C”），并欺骗那些认为他们要访问“cats.com”（拉丁字母“C”）的用户。

很好的例子说明了新功能如何破坏了安全假设。

浏览器供应商认为注册商将禁止模糊名称。
注册商认为浏览器供应商将更改浏览器以执行某些操作。

MIT 6.858 计算机系统安全讲义 2014 秋季（二）（3）https://developer.aliyun.com/article/1484152

MIT 6.858 计算机系统安全讲义 2014 秋季（二）（2）