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 的处理器刚刚可用
  
• 没有部署经验
  

• TCB

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

• 伊阿戈攻击

• 操作系统能在 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 页面映射到多个虚拟地址

• 需要修改应用程序

• 安全性？

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

参考资料

1. Iago 攻击
   
2. SGX 概述
   
3. SGX 指令概述
   
4. SGX 硬件
   
5. SGX 安全讨论
   
6. 抽象桥
   

网络安全

注意： 这些讲座笔记是从 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 等。
  

• 四个主要思想：

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

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

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

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

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

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

4. 被动内容（例如图片和 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，即使两者的值相同！
  
• 两个框架可以相互访问，如果：

1. 他们都将document.domain设置为相同的值，或者
   
2. 两者都没有更改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 代码。
  
• 方法：

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

• 解决方案：

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

屏幕上的像素怎么办？

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

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

• 解决方案

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

• if(top != self)

2. 让你的网络服务器发送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