麻省理工学院。 讲座课程＃6.858。 “计算机系统的安全性。” Nikolai Zeldovich，James Mickens。 2014年
计算机系统安全是一门有关开发和实施安全计算机系统的课程。 讲座涵盖了威胁模型，危害安全性的攻击以及基于最新科学研究的安全技术。 主题包括操作系统（OS）安全性，功能，信息流管理，语言安全性，网络协议，硬件安全性和Web应用程序安全性。
第1课：“简介：威胁模型”
第1 部分 /
第2 部分 /
第3部分第2课：“控制黑客攻击”，
第1 部分 /
第2 部分 /
第3部分第3讲：“缓冲区溢出：漏洞利用和保护”
第1 部分 /
第2 部分 /
第3部分讲座4：“特权分离”，
第1 部分 /
第2 部分 /
第3部分讲座5：“安全系统从何而来？”
第1 部分 /
第2部分讲座6：“机会”
第1 部分 /
第2 部分 /
第3部分讲座7：“本地客户端沙箱”
第1 部分 /
第2 部分 /
第3部分讲座8：“网络安全模型”
第1 部分 /
第2 部分 /
第3部分 那么，如果浏览器无法正确处理对象并且无法识别其类型，会发生什么呢？ 在这种情况下，您可能会遇到安全问题。 其中之一称为MIME攻击。
您可能熟悉MIME-这是一种未加密的标头，例如text / html，image.jpeg等。 因此，较旧版本的IE浏览器使用了此功能，因为他们认为这会对用户有所帮助。 但是有时候，Web服务器会为目标文件分配错误的扩展名。
配置错误的Web服务器可以将后缀.html附加到其实际具有扩展名.jpeg的文件上，反之亦然，例如，创建foo.jpg而不是foo.html。
因此，在过去，IE试图为您提供帮助。 也就是说，他去了某种资源，同时想着：“好的，根据文件扩展名，该资源声称是这种类型的。” 但随后，他将仅查看此对象中可用的前256个字节。 如果他发现那里有某种神奇的含义，表明该对象有不同的扩展名，他会简单地说：“嘿，我在这里发现了很酷的东西！ “我认为Web服务器错误地定义了该对象，所以让我只将此对象视为在前256个字节中发现的类型。”
然后每个人都成为赢家，因为像这样的浏览器帮助了Web服务器的开发人员，因为从现在开始，他们的网站将得到正确显示。 并且用户会喜欢它，因为他们将能够解锁以前只是垃圾的内容。
但这是一个明显的漏洞！ 假设页面包含一些被动内容，例如，来自攻击者控制域的图像。 但是，受害者的页面认为：“即使这是恶意黑客网站的内容，也只是被动内容。 他对我无能为力！” 在极端情况下，将显示不成功的图像，但由于被动内容具有零特权，因此它将无法打开任何代码。
但是事实是IE可以先“嗅探”此图像（前256个字节）。 攻击者可以有意地在其中放置HTML和JavaScript代码。 事实证明，受害人的站点将带来它认为是图像的内容，而IE将在嵌入式页面的上下文中执行恶意代码。
这是一个例子，说明浏览器的复杂程度，以及添加非常好的意图都会导致非常微妙的安全性错误。 因此，让我们仔细看一下浏览器如何保护各种资源。
让我们看一下框架和窗口对象（作为包含DOM文档的窗口的对象）。 框架代表了我们在这里讨论的这些独立的JavaScript世界。 我的意思是，JavaScript是DOM节点的实例，如DOM树的图片所示。
这样，框架将作为DOM节点对象存在于此层次结构中JavaScript可见的某个位置。
在JavaScript中，窗口对象实际上是全局名称空间的别名。 听起来像个愚蠢的主意。 也就是说，如果要找到全局变量x的名称，则还可以通过名称window.x访问它。
因此，框架和窗口对象是非常强大的引用，可为您提供可访问性。 并且它们包含彼此的指针。 框架可能包含指向链接的窗口对象的指针，反之亦然。 实际上，这两件事是等效的。
框架和窗口对象都从URL框架获取原始来源，或者因为它们始终位于网络的安全部分，所以它们可以获取原始域名的后缀，即原始域名。
例如，一个帧可能是这样开始的：.xyzcom，在这里您可以忽略方案和协议一秒钟。
在这种情况下，我们可以假设（document.domain）的来源是后缀yzcom。 同样，此文档的来源是表达式z.com。 这是可能的，因为z.com是yzcom的后缀。
唯一不能用作此类源的是表达式.ayzcom，因为它是来源源origin的错误后缀。 同样，不能简单地将原始来源的源后缀视为.com，因为在这种情况下，该网站将能够以某种方式影响Cookie或类似.com的任何网站上的类似内容，这可能会带来灾难性的后果。
之所以接受这些类型的事物的动机是，它与某种类型的现有信任关系有关。 因此，似乎前三个参数都是按顺序排列的，无序仅出现在.com中。
观众：事实证明，有可能在任何时候或终点进行这样的分裂吗？ 例如，您的xyzcom可以更改为z.com吗？
教授：不，这仅适用于每一点。
受众：是否有一个未这样做的原因，以便您可以指示超级域或子域，但与此同时，他们应该以某种方式就信息的来源达成共识？ 假设我只想接受与我的起源相同的事物，以便任何这些资源都可以攻击我。 此外，我们将使这种交互对称，以便我也可以影响它。 毕竟，源后缀.com表示任何具有相同.com后缀的东西都可能影响我。
教授：是的，这很困难，所以这个问题有几个答案。 首先，人们非常担心.com遭受攻击的可能性。 因此，他们希望使域操作语言易于理解。 因此，它们不允许破坏设置。
我将在第二秒中谈论一件事，它允许您执行所谈论的事情，但仅涉及域后缀。 现在，我要指出的是，“帖子消息”界面允许域在同意的情况下彼此通信。 因此，在实践中，如果人们无法使用上述技巧建立相同的来源，则可以使用Post Message来实现跨域通信。 这样，浏览器可以根据源域的这些后缀来限制域。 这里还有一个有趣的细微差别-浏览器了解何时可以写入（document.domain），何时不能写入。
这是有原因的，我们将在稍后考虑。 因此，如果满足以下两个条件中的至少一个，则两个帧可以互相访问：
- 两组框架集（document.domain）的值相同；
- 尽管两个框架中此文档的值都相同，但这些框架都不能更改（document.domain）。
这些规则的主要思想是，它们可以保护域免受自身错误或子域之一的危害所引起的攻击。
假设您有一个xyzcom域正试图攻击yzcom域，因为第一个域包含错误或恶意。 他将尝试将yzcom域缩短为.com外观，然后开始利用JavaScript或cookie或其他内容的状态来“化装”。
因此，这两个规则意味着，如果yzcom不想允许任何人与之交互，则它将永远不会更改值（document.domain）。 因此，当xyzcom框架想要缩短它时，浏览器会说：“是的，您想缩短它，但您无权这样做！” 值是一致的，但是yzcom域尚未表明它希望参与其中。 清楚吗？ 在这种情况下，可以看出大多数帧都使用相同的原始策略。
现在我们可以看到如何处理DOM节点。 这很简单。 通常，DOM节点从周围框架中获取原点。 就cookie而言，这要复杂一些。 Cookies有一个域，它们有自己的方式。 例如，您可以想象一个cookie可以与以下信息相关联，例如* .mit.edu / 6.858。 在这种情况下，Cookie具有* .mit.edu /域和路径6.858。
请注意，该域可能是当前域中页面的完整后缀。 因此，您可以与他一起执行与我们之前讨论的相同的技巧。 请注意，此路径6.858也可以表示为斜杠，后跟什么也不表示，表示所有域路径都必须可以访问此处的cookie。
但是在这种情况下，我们有一个特定的路径地址。 因此，无论谁设置了这些cookie，他都有机会查看域和路径的样子。 这些值可以在服务器端和客户端上设置。 在客户端，您将有一个名为document.cookie的JavaScript对象。 这是用于指示指向相似对象的所有路径的格式。
您可以在cookie上设置一个安全标志安全标志，以表明它是HTTPS文件。 在这种情况下，HTTP内容不应有权访问此cookie。 这是cookie的主要思想。
请注意，每当浏览器生成对特定Web服务器的请求时，它将在此请求中包括所有相关的cookie。 有一种对应关系和算法，可以发现它们是应响应请求而发送的正确cookie，因为它们可能带有域名后缀等奇特的东西，依此类推。
受众：如果框架遵守这些规则，那么框架可以访问彼此的cookie吗？
教授：是的，框架可以做到这一点。 但这取决于如何设置document.domain，cookie域和路径。 因此，框架可以访问彼此的cookie，因此出现了一个问题：如果我们允许任意框架向人们写入任意cookie，会不会有问题？ 可以说这是不好的。 之所以不好，是因为这些cookie允许应用程序的客户端存储用户数据。
因此，您可以想象，如果攻击者可以控制或重新定义用户cookie，例如，他可以更改Gmail的cookie，以便用户通过属于此攻击者的Gmail帐户登录。 在这种情况下，攻击者可能会读取任何用户字母。 您可以想象某人将能够从Amazon.com上获取Cookie，并将各种荒谬的购买之类的东西放入您的购物篮。
因此，cookie是非常重要的保护资源。 许多网络安全攻击旨在窃取并利用它们造成危害。
还有另一个与cookie有关的有趣问题。 假设您有一个站点foo.co.uk。 如果具有该主机名的站点能够为co.uk设置cookie，该怎么办？
这里与我们前面讨论的规则有关，有一个微妙之处，因为第一个站点应该能够缩短其域并为第二个站点设置cookie，所以这里的一切似乎都是合法的。 但是从人类的角度来看，我们对此表示怀疑，因为我们知道co.uk是单个原子域。 但是，这等效于.com。 可以说，英国人搞砸了，他们在这里应该有一点。 但这不是他们的错。 从道德角度来看，这是一个不可打破的单一领域。 因此，我们必须具有一些特殊的基础结构才能设置cookie使其正常工作。
Mozilla有一个名为publicsuffix.org的网站，其中包含有关应如何缩短Cookie，起源和域的规则列表，同时考虑到某些事物中可能存在点，而实际上应将它们视为单个原子。整体。
因此，当您的浏览器发现应如何操作不同的Cookie时，则必须检查问题的这一方面。 或者以某种方式确保foo.co.uk不能将域名缩短为co.uk。 因此，这里有一个非常敏感的问题。
在此过程中，我们发现了许多有趣的Web安全问题，因为许多原始基础结构是专门为英语开发的。 例如，ASCII文本或类似的内容。 它最初不是为国际社会设计的。
但是，随着Internet变得越来越流行，人们开始说：“嘿，一开始我们创建了相当大的解决方案设计，现在我们必须使其适合那些被迫对语言含义狭narrow理解的人们。” 因此，我们现在面临所有这些疯狂的问题。
考虑相同的原始源策略如何处理HTTP XML响应。 默认情况下，如果JavaScript是在其原始服务器上构建的，则只能生成其中之一。 但是，有一个名为“跨源请求”或CORS的新接口。
因此，这是相同的起源，除非服务器启用了此CORS gizmo。 基本上，添加了一个新的HTTP响应标头，称为Access-Control-Allow-Origin。
假设来自foo.com的JavaScript希望向bar.com发出XML HTTP请求。 如规则中所述，交叉起点在此处发生。 如果bar.com服务器想要允许它，它将返回带有标题的HTTP响应：“是的，我让foo.com向我发送这些跨域XML XML请求。”
实际上，bar.com服务器可以回答“否”，也就是说，它可以拒绝该请求。 在这种情况下，浏览器无法完成HTTP XML请求。 因此，这是一种新事物，主要是由于混合应用程序而出现的。 来自不同开发人员和不同域的应用程序都需要它，以便他们有机会彼此交换数据。
因此，如果有人要获取跨源数据，则可能在这里没有星号foo.com，依此类推。 我认为这很简单。 我们还有很多其他资源，例如图像。 多亏了Access-Control-Allow-Origin，框架可以从所需的任何来源加载图像。 但是他无法检查此图像的位，因为据信，采用不同的来源策略，检查彼此文件的内容是不好的。
尽管框架无法检查位，但仍可以推断图像的大小，因为它可以看到图像在页面上的放置方式。 因此，这是另外一种奇怪的情况，据称同一来源策略试图防止所有信息泄漏。 但是实际上，它不能阻止所有这些，因为嵌入继承实际上显示了某些类型的信息。
CSS与图像相似，因此框架可以嵌入任何来源的CSS。 但是，它不能直接检查CSS文件中的文本是否来自其他来源。 但是他可以识别此CSS的功能，因为他仅创建了一堆节点，然后观察它们的样式如何变化。 而且看起来有些奇怪。
JavaScript是我最喜欢的示例，它说明了这种相同的来源策略如何尝试支持任何类型的智能序列。 这里的想法是，如果交叉获取JavaScript，则允许这样做。 您可以在自己的页面上下文中启用外部JavaScript的执行，但不能查看源代码。
因此，如果您的脚本标记源等于域外的某个源，则在执行该源时，可以在其中启动功能。 但是您将无法查看其中的JavaScript源代码。
所有这些看起来都很好，但是有很多“漏洞”。 例如，JavaScript是一种动态脚本语言。 函数是一流的对象。 因此，对于任何函数f，您都可以简单地使用函数f.tostring（），这将为您提供函数f的源代码。 人们一直在这样做，他们在进行动态重写等。
因此，尽管起源策略不允许您直接查看script标记的内容，但是您可以简单地执行指定的操作并获取源代码。
同样，您可以从域中获取主服务器，只是在其上获取源代码，然后将其发送回给您。 也就是说，实际上，您只是要求家用服务器运行Wget程序以这种方式获取源代码。 因此，它看起来也有些愚蠢，也就是说，这里的原籍政策有点奇怪。
受众：假设他们这样做的原因是为了防止用户接收JavaScript，因为这样也可以发送cookie。 也就是说，用户将能够使生成的JavaScript适应他的需求。
教授：是的。
受众：因此，如果让您的服务器执行此操作，它将无法为您提供自定义cookie。
教授：这是对的，尽管实际上“原始”源代码不旨在由用户重做。 但是您说对了，这样可以防止某些攻击。
, , JavaScript, . , - , -, , . , , , . , , .
, . - - , - HTML JavaScript. , , . .
, JavaScript, , . Java, .
, HTML5 , , , , Java. , .
, HTTP, cookie. , URL, ?
, URL- bank.com. , - . , URL, , , $500 . , .
— , origin, bank.com - , , cookie . : «, , , $500 attacker! , ».
. , , , , . . , , , , - . , , CSRF.
, URL. , c .
, - . – , , :
<form action = “/transfer.cdi”…>
在此表单中，我们将获得输入数据，该数据通常用于输入文本，击键，鼠标单击等。 实际上，我们可以隐藏此输入，以使其不会出现在用户页面上：输入类型=“隐藏”，为其提供属性名称=“ csrf”和随机值=“ a72f ...”。 该表格将在服务器上生成。
因此，当用户访问此页面时，在服务器端，服务器将生成此随机性值=“ a72f ...”，并将其嵌入到用户接收的HTML中。 因此，当用户填写此表单时，该URL如下：
bank.com/xfer?amount=500&to=attacker它补充有一个随机令牌：
http:
这意味着现在，攻击者应该能够在每次用户访问银行页面时猜测服务器为用户生成的特定令牌。 因此，如果我们具有足够的随机值，那么黑客将无法伪造任何东西，因为如果他指示了错误的令牌，则服务器规则将拒绝他的请求。
58:00分钟
延续：
麻省理工学院的课程“计算机系统安全”。 讲座8：网络安全模型，第3部分该课程的完整版本可
在此处获得 。
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的资料吗？ 通过下订单或将其推荐给您的朋友来支持我们，
为我们为您发明的入门级服务器的独特模拟，为Habr用户提供
30％的折扣： 关于VPS（KVM）E5-2650 v4（6核）的全部真相10GB DDR4 240GB SSD 1Gbps从$ 20还是如何划分服务器？ （RAID1和RAID10提供选件，最多24个内核和最大40GB DDR4）。
VPS（KVM）E5-2650 v4（6核）10GB DDR4 240GB SSD 1Gbps至12月免费，在六个月内付款，您可以
在此处订购。
戴尔R730xd便宜2倍？ 仅
在荷兰和美国，我们有
2台Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100电视（249美元起） ！ 阅读有关
如何构建基础架构大厦的信息。 使用价格为9000欧元的Dell R730xd E5-2650 v4服务器的上等课程？