浏览器中的安全窗口通信

本文为论文《Securing Frame Communication in Browsers》的读书笔记。

该论文基于浏览器的安全策略，主要着眼于浏览器中的窗口通信(frame communication)。

现在随着网民的不断增多，浏览器在用户的网络生活中扮演着一个不可或缺的角色，但是浏览器在显示用户所需的网页时，并非是安全的。现在绝大多数的网站在窗口中植入第三方的内容，而对于用户来说，主要依靠浏览器的安全策略来保证不受恶意内容的攻击或者影响。在浏览器中，窗口其实并不是很充分的独立存在，因为现在越来越多的浏览器，允许窗口内容可以通过导向来控制其他的窗口。

在该论文中，评估了现有的一些窗口导向策略，并且倡导浏览器执行一种更加严格的策略。首先，可以看到的是，窗口之间的隔离必定会或多或少的影响窗口之间的通信。对于以上结论，作者分析了窗口间通信的两种技术：fragment identifier channel和postMessage。首先，第一种技术fragment identifier channel，它提供了保密的通信但是却不能保证通信的身份验证。而第二种技术postMessage，它提供了通信的双方身份验证，但是却在现实应用中发现有一些攻击者可以破坏其中的保密性。作者通过修改postMessage API 接口来实现窗口通信的保密性。

正文中，作者在介绍窗口通信的时候，涉及到了三个术语：mashup，integrator，gadget。其中mashup代表网站将好几个源发过来的内容整合的过程，integrator代表整合这些内容的主动方，gadget则代表被整合的内容。

在浏览器的实际工作中，浏览器的窗口内容之间会存在两种状态，一种是相互孤立（isolation），另一种是相互通信（communication）。孤立的好处是，窗口之间的运行不受彼此的影响，即一个窗口不会产生对其他窗口的导向。这看似简单严谨，但是随着浏览器的发展，这个窗口策略变得不符合实际的需求，从而使得浏览器的质量有所影响。由于严格的孤立策略，浏览器中窗口间的交互变得很受限制，从而使得孤立的窗口间协作通信变成了一个不得不重视的问题。在这个问题地研究过程中，业界出现两种窗口间通信的方法：fragment identifier channel和postMessage。

由于浏览器窗口通信中存在安全问题，故作者在随后的一个模块介绍了浏览器上的危险模型（Threat Model）。其中基于浏览器的最主要的攻击是，破坏浏览器窗口间的交互，或者窃取一些敏感的隐私信息。这些攻击的方式是在浏览器中植入恶意内容，或者修改浏览器中的某些状态。

在介绍完Threat Model以后，作者花大篇幅来叙述了现有的窗口导向策略，并粗略的讲述了目前众多流行的浏览器使用的策略。

作者从窗口孤立（frame isolation）出发，毕竟窗口的通信都是在这基础上的更进一部，从一开始的脚本策略和导向策略。脚本策略主要通过在一个窗口中的脚本来控制其他的窗口，这样的话把窗口间的很多实现都转交给脚本。导向策略的主要思想是一个窗口可以导向任何其他的窗口。这样的好处主要是可以通过在从URL中获取的内容来替换窗口的文档内容。

作者还介绍了两种攻击：Cross-Window Attack和Same-Window Attack。

Cross-Window Attack主要是基于用户需要在某一个窗口中输入登录信息（帐号密码等），一旦该窗口中包含有向恶意网站的导向，那么这些信息将有可能会被攻击将输入信息窗口的内容发送到恶意网站。对于这样的攻击有一种很严格的策略防止，那就是Window Policy，也就是说一个窗口只允许导向这个窗口内的其他窗口。

可以说Window Pocily是一个很好的策略，但是这并不代表它可以被广泛地应用到如今的浏览器中，原因很简单，那就是发展过程中，mashup完全违反了它的安全假设，也就是用户不会植入不受信任的内容。

既然mashup违反了window policy的假设，所以在mashup的过程不能保证不受攻击。这样的攻击主要有Gadget HijackingAttacks。在这类攻击中，攻击者可以控制被合法integrator植入的gadget，从而攻击拥有了攻击的平台。也就是说，一个恶意的gadget可以控制一个gadget导向恶意网站，从而向用户扮演这个gadget的角色。

由于在mashup的过程中也会出现安全问题，所以在实际运行中需要更加严谨的策略来支持浏览器窗口通信的安全。所以除了以上比较宽松的window policy以外，还有两种另外的窗口导向策略： Descendant Policy和Child Pocily。前者是允许窗口可以导向到他的子孙处，而后者只允许它导向到它的儿子处，可见后者要比前者更加严格。

而后，作者讲述了一种技术：像素代表（Pixel Delegation）。可见Descendant Policy采取了在安全和兼容性之间的完全权衡，因为它并不是那么严格。所谓像素代表，也就是父窗口在子窗口看来只是代表了屏幕上的一个像素区域。浏览器可以防止子窗口超越这些屏显范围。

在介绍完威胁模型和窗口导向策略以后，作者讲述了窗口通信的机制。主要是基于两个通信方法：fragment identifier channel和postMessage。

fragment identifier channel可以使得mashup开发者在单独的窗口中安置每一个gadget，并依靠浏览器的安全策略来实现防止恶意gadget攻击integrator和受信任的gadget。

为了理解该方法中的安全属性。如果一个信息是保密的话，那也就是这个信息只能被这个信息的接受方读取。但是这个机制却是一个缺乏安全的信道，因为它缺少身份认证，也就是说当一个接受方接收到一个信息的时候，它不具备能力来辨别这个信息到底是谁发过来的，所以说这个机制是不具备身份验证的。另外该方法的安全属性是通过公钥加密来实现的。一方面公钥极易容易收到网络的感染，另一方面该机制主要受限于浏览器中的窗口导向策略。当然也可以通过一些加强的协议使得该机制变得安全，比如说使用Needham-Schrooeder-Lowe协议。

和fragment identifier channel不同的是，postMessage的设计主要是为了网站间通信的。

在浏览器中如果一个窗口需要向另一个窗口发送一个信息的话，那么发送方只需要调用一个postMessage方法就可以了。然后浏览器会生成一个message事件，这个事件会包含消息，发送方的源，还有一个指向这个窗口的指针。

可以看到postMessage的安全属性中可以做到身份验证，因为在发送的这个信息中，需要包含发送方的源，这样的话接收方对于信息的来源是可以获知的。但是它却缺乏信息的保密性。

大家普遍认为postMessage是一个安全可靠的窗口通信方法，但是攻击可以攻击信息的保密性对信息进行攻击。其中包括Recursive Mashup Attack，Reply Attack。

关于安全的postMessage，作者也介绍了一些方法，其中就有在该方法的基础上添加另一种API CommRequest。因为这个API接口只会传输到特定的一定方，这样的话也就多了身份验证。