Pretty-Bad-Proxy: III. SCRIPT-BASED PBP EXPLOITS

III. SCRIPT-BASED PBP EXPLOITS   

基于脚本的PBP攻击

Scripting is a critical capability of modern browsers. However, they impose more risks than static HTML contents if the scripting mechanism is not carefully designed and evaluated against different types of adversaries. Cross-site scripting [13] and browser crossdomain attacks [4] are the representative examples of vulnerabilities exposed by scripting. While these attacks have provoked many discussions in the web security community, so far there has been less attention on the possibility of script-based attacks against HTTPS when the proxy is assumed the adversary.

脚本是现代浏览器一个至关重要的能力。然后，如果脚本机制没有针对不同类型的攻击者进行小心的设计和评估，他们会比静态HTML带来更多的风险。跨站脚本和浏览器跨域攻击是利用脚本进行攻击的典型漏洞例子。由于这些攻击已经在网络安全界激起过非常多的讨论，到目前为止针对假设代理是攻击者而进行的基于脚本攻击的可能性的讨论已经越来越少的得到关注。

In this section, we will describe several script-based attacks, some of which are because of executing regular HTTP scripts in the HTTPS context while others are because of executing scripts from unintended HTTPS websites in the context of target HTTPS websites. These attacks raise a concern that browsers’ scripting mechanisms have not been thoroughly examined under the PBP adversary.

本部分，我们将描述几中基于脚本的攻击手段，一部分是因为在HTTPS里执行通常的HTTP脚本，另一部分则是因为在目标HTTPS站点里执行不想要连接的HTTPS站点里的脚本。这些攻击引起了一种关注：浏览器的脚本机制在PBP攻击方式下没有被彻底的检查过。

A. Embedding Scripts in Error Responses

A. 错误响应里的植入脚本

We explained earlier that the browser sends an HTTP CONNECT request to the proxy when it tries to access an HTTPS server through the proxy. Sometimes the proxy may fail in connecting to the target server, in which case the proxy should send an HTTP error message back to the browser. For instance, when the browser requests https://NonExistentServer.com, the proxy will return an HTTP 502 Proxy Error message to the browser because the proxy cannot find a valid IP address associated with the server name NonExistentServer.com. Note that the communication between the browser and the proxy still uses plain-text up to this point. Interestingly enough, the browser renders the error response in the context of https://NonExistentDomain.com, although the server does not exist. We observed this behavior on all browsers that we studied. In addition to HTTP 502, other HTTP 4xx and 5xx messages are treated in a similar way. 

前面我们解释过，当一个浏览器试图通过代理访问HTTPS服务器的时候，它会向代理发送一个HTTP连接请求。有时候代理连接目标服务器到时候可能失败，这时候代理会发送一个HTTP错误信息返回给浏览器。举个例子：当浏览器请求https://NonExistentServer.com，代理将返回HTTP502 Proxy Error信息给浏览器，表示代理无法找到一个对应于域名NonExistentServer.com的有效IP。注意此时在浏览器和代理之间的通信仍然使用无序字符序列。有趣的是，虽然https://NonExistentDomain.com这个服务器并不存在，浏览器还是渲染了错误响应。我们在所有我们研究的浏览器上发现了这个行为。除了HTTP 502，其他HTTP4XX和5XX信息处理类似。

Since the browser completely relies on the proxy for the tunneling, the proxy can arbitrarily lie to the browser, which leads to the compromise of HTTPS confidentiality and authenticity. We now use an example to illustrate how a PBP adversary can steal the sensitive data from the browser when it is visiting an HTTPS server. Suppose the browser is accessing https://myBank.com, upon receiving the HTTP CONNECT request from the browser, the proxy may pretend that the server did not exist by returning an HTTP 502 error message. The error message also includes an iframe (inline frame) and a script. When the browser renders the error message, the iframe will cause the browser to send another CONNECT request for https://myBank.com. The proxy will behave normally this time by tunneling the communication to the server. Thereafter, user’s banking data will be loaded into the iframe (abbreviated as ifr). However, the script embedded in the original error message has been running in the context of https://myBank.com. This allows the script to reference ifr.document and send the user’s banking data (e.g., body.innerHTML) to a third party machine, circumventing the same-origin policy of the browser. Besides peeking the user’s banking data, the attacker can also transfer money from the bank on behalf of the user.

因为浏览器完全依靠代理进行隧道传输，代理随时可以欺骗浏览器，也就导致了HTTPS的保密性和可靠性被影响。我们用一个例子来阐明一个PBP攻击者如何在他访问HTTPS服务器时从浏览器窃取敏感信息。假设浏览器正访问https://myBank.com，当接收到浏览器传送过来的HTTP连接请求的时候，代理可能返回HTTP502错误信息来假装服务器不存在。这个错误信息也包含一个内置框架和一段脚本。当浏览器渲染错误信息时，内置框架将应发浏览器向https://myBank.com再次发送一个连接请求。代理这次将正常将通过隧道将连接发送到服务器。那之后，用户的银行信息将被加载到内置框架.然而，嵌入在错误信息里的脚本将在https://myBank.com里执行。这允许这段脚本引用ifr.ducument并将用户的银行数据（比如body.innerHTTML）发送到一个第三方机器，绕过浏览器的同源策略。通过窥探用户的银行数据，攻击者也可以在用户操作时将钱从银行转出。

The attack does not depend on which authentication mechanism is used between the victim and the server. For instance, if the server uses password authentication, the proxy can behave benignly until the victim successfully logs on, and then launch the attack. The situation is much worse if the server uses Kerberos authentication (similarly, NTLM authentication), in which case the authentication happens automatically without asking the user for the password. The attack can be launched even when the victim does not intend to visit the HTTPS server: whenever the victim visits a website http://foo.com, e.g., a popular search engine, the proxy may insert the following invisible iframe into the webpage of foo.com to initiate the same attack. <iframe src=”https://SiteUsingKerberos.com” style=”display:none”></iframe>

这种攻击不依赖于受害者和服务器之间的验证机制。举个例子，如果服务器使用用户密码的认证机制，代理可以一直表现友好，直到受害人成功登陆，然后发起攻击。当服务器使用KERBEROS认证系统时（译者注：麻省理工学院开发的安全认证系统），认证自动进行，甚至都不需要用户提供密码，这种情况危害更大。攻击者可以在受害者不访问HTTPS服务器时发起攻击：任何时候，当受害者访问http://foo.com（举个例子），一个流行的搜索引擎，代理可能插入以下内容框架到foo.com的网页来初始化一样的攻击。 <iframe src=”https://SiteUsingKerberos.com” style=”display:none”></iframe>

Kerberos is typically used in enterprise networks. This vulnerability allows the proxy to steal all sensitive information of the victim user stored on all HTTPS servers in the enterprise network, once the user visits an HTTP website

KERBEROS认证在企业网中是一个典型应用。一旦用户访问HTTP网站，这个漏洞允许代理窃取受害者存储在企业网中HTTPS服务器上的所有的敏感信息。

B. Redirecting Script Requests to Malicious HTTPS Websites 

B.重定向到恶意网站

After describing the PBP attacks based on the mishandling of HTTP 4xx and 5xx error messages in browsers, we now turn to another security flaw that can be exploited when browsers are dealing with HTTP 3xx redirection messages.

在描述了基于浏览器对HTTP 4XX和5XX错误信息的失误处理而引入的PBP攻击，我们现在转到另一个安全漏洞，它在浏览器处理HTTP 3XX的重定向信息的时候可以被利用。

A benign redirection scenario is: when the user makes a request to https://a.com, the proxy can return a response, such as “302 Moved temporarily. Location: https://b.com”, to redirect the browser to https://b.com. Similar to the previous scenario, the redirection message is in plain-text. The redirection is explicitly processed by the browser, so there is no confusion about the security context of the page – the page of the redirection target will be rendered in the context of https://b.com. In other words, a request redirected to https://b.com is equivalent to a direct request to https://b.com. There seems no security issue here.

一个友好的重定向场景是：当用户访问https://a.com，代理返回一个类似“302 Moved temporarily. Location: https://b.com”的响应来将浏览器重定向到https://b.com。类似前一个场景，重定向信息是纯文本的。重定向很明确是浏览器处理的，所以网页的安全内容没有质疑，重定向网页目标将在https://b.com中被渲染。换句话说，重定向到https://b.com的请求等同于一个到https://b.com的直接请求。这里看上去没有什么安全问题。

However, the ability for a proxy to redirect HTTPS requests can be harmful when we consider the following scenario: many webpages import scripts from different servers. For instance, a page of https://myBank.com may include a script https://scriptDepot.myBank.com/foo.js or a third-party script https://x.akamai.net/foo.js. According to the HTML specification, a script element does not have its own security context but instead runs in the context of the frame that imports it. To launch an attack, a proxy may simply use a 3xx message to redirect an HTTP CONNECT request for https://scriptDepot.myBank.com or https://x. akamai.net to https://EvilServer.com. This will cause the script https://EvilServer.com/foo.js to be imported and run in the context of https://myBank.com. Once the script runs, it can compromise the confidentiality and authenticity of the communication in a similar manner as described previously.

然而，当我们考虑以下场景时，代理可以重定向HTTPS请求的能力将会有危害性：很多网站从不同的服务器导入脚本。举个例子：一个 https://myBank.com 的网页可能包含脚本https://scriptDepot.myBank.com/foo.js 或三方脚本 https://x.akamai.net/foo.js。根据HTML规范，脚本元素没有自己的安全上下文，而是在引入它的框架中运行。为了发起攻击，代理可能简单的用一个3XX信息来重定向一个来自https://scriptDepot.myBank.com or https://x. akamai.net的HTTP连接请求到 https://myBank.com。这将使 https://myBank.com引入并运行 https://EvilServer.com/foo.js 脚本，一旦这个脚本执行，它可以使用前文描述的很简单的方式破坏通信的机密性和可靠性。

This attack affects Firefox, Safari and Opera. IE and Chrome are immune because they only process HTTP 3xx messages after the SSL handshake succeeds. In other words, 3xx messages from the proxy are ignored by the browser for HTTPS requests. 

这个攻击影响Firefox，Safari和Opera。IE和Chrome因为在SSL握手成功之后只使用HTTP 3xx的信息，所以幸免于难。换句话说，代理发来的3xx信息被浏览器的HTTPS请求忽略了。

C. Importing Scripts into HTTPS Contexts through “HPIHSL” Pages

通过HPIHSL页面往HTTPS内容导入脚本

Many web servers provide services of HTTP and HTTPS simultaneously. Normally, sensitive webpages, such as user login, personal identification information, and official announcement, are accessible only via HTTPS to prevent information leak and forgery. Less critical webpages are accessible via HTTP for reduced processing overhead. Webpages often need to import additional resources, such as images, scripts, and cascade style sheets. When a page is intended for HTTP, the resources are usually fetched using HTTP as well, because the page is not intended to be secure against the malicious network anyway.

很多网站服务器同时提供HTTP和HTTPS服务。通常来说，例如用户登陆，个人认证信息、官方声明等敏感页面，只能通过HTTPS访问，避免信息泄露和被伪造。严重级别不那么高的网页一般通过HTTP来访问，以降低处理开销。网页经常需要加载列入图片，脚本，CSS样式表等附加资源。当一个网页使用HTTP，这些资源一般也使用HTTP获取，因为这个网页并不打算在恶意网络中保持完全。

However, the reality is that although less-sensitive webpages are intended to be accessed via HTTP, most of them actually can also be accessed via HTTPS. We refer to these pages as HTTP-Intended-but-HTTPS-Loadable pages, or “HPIHSL pages”. When a HPIHSL page loaded in the HTTPS context imports resources using HTTP, browsers display different visual warnings: 1) IE pops up a yes/no dialog window. If user clicks no, the resources retrieved via HTTP will not be rendered and the lock icon will stay in the address bar. Otherwise, the resources will be rendered but the lock icon is removed; 2) Firefox pops up a warning window with an OK button. After user clicks it, the HTTP resources are rendered and a broken lock icon is displayed on the address bar. 3) Opera and Chrome automatically remove the lock icon (or or replace it with an exclamation mark) to indicate that HTTP resources have been imported.

然而，事实上虽然弱敏感网页希望通过HTTP访问，实际上他们大部分也可以通过HTTPS访问。我们把目标转向这些希望通过HTTP但是支持HTTPS访问的网页，也就是“HPIHSL 网页”。当一个HPIHSL网页加载网页使用HTTPS，而加载资源使用HTTP，浏览器现实不同的警告：1.IE弹出yes/no对话框.如果用户点击no，通过HTTP加载的资源将不被渲染，地址栏会长期存在一个锁图标。否则，资源会被渲染，但是所图标会被移除。2.Firefox弹出一个带OK按钮的警告框。当用户点击，HTTP资源会被渲染，地址栏会出现一个被破坏的锁的图标。3.Opera和Chrome自动移除锁图标（或者替换成感叹号）来表示HTTP资源被导入。

We found that the code logic for detecting HTTP contents in HTTPS pages is triggered only when the browser needs to determine whether to invalidate/remove the lock icon on the address bar, which is only correspondent to the top-level frame of the browser. Therefore, when the top-level frame is an HTTP page, the detection is bypassed even when this HTTP page contains an HTTPS iframe that loads an HPIHSL page.

我们发现在HTTPS发现HTTP内容的代码逻辑只有在浏览器需要决定是否在地址栏将锁按钮移除或使之失效的时候才会被处罚，这只有在浏览器顶层框架才适配。所以，当顶层框架是HTTP网页，这种探查就被绕开了，哪怕是这个HTTP网页包含了一个会加载HPIHSL网页的HTTPS框架。

This turns out to be a fatal vulnerability for many real websites. For example, a PBP can steal the user’s login information from the HTTPS checkout page of j-Store.com (the first row of Table I): when the user visits an HTTP merchandise page on j-Store.com, the proxy can insert the following invisible iframe into the page: <iframe src=”https://www.j-Store.com/men- shoes.html” style=”display:none”> </iframe>

这个变成了一个很多真实网站的致命漏洞。举个例子,一个PBP攻击者可以通过j-Store.com(表1第一行)网站的HTTPS登出网页窃取用户登陆信息：当一个用户访问一个该网站上的一个HTTP商品页面，代理可以将以下脚本插入网页：<iframe src=”https://www.j-Store.com/men- shoes.html” style=”display:none”> </iframe>

Without users’ awareness, the invisible iframe loads the HPIHSL page men-shoes.html via HTTPS. Because this page requests a script from http://switch.atdmt.com/jaction/ via HTTP, the proxy can provide a malicious script to serve the request. Since the script is in the inserted iframe, it will run in the context of https://www.j-Store.com. The PBP also overwrites the “checkout” button on the HTTP merchandise page so that when the user clicks on it, the HTTPS checkout page opens in a separate tab. The personal data entered by the user therefore can be easily obtained by the proxy’s script in the invisible iframe. In addition, the proxy can impersonate the logon user to place arbitrary orders. We believe that this is a significant browser weakness: as long as any HPIHSL imports scripts or style-sheets (usually via HTTP as explained), the HTTPS domain is compromised.

不需要用户感知，这个不可见的iframe使用HTTPS加载了men-shoes.html这个HPIHSL网页。因为这个网页使用HTTP向http://switch.atdmt.com/jaction/的请求脚本，代理可以提供恶意脚本来满足这个请求。因为这该脚本在插入ifame里，它可以在https://www.j-Store.com里运行。PBP也可以重写HTTP商品页面上的checkout按钮，这样当用户点击它的时候，HTTPS登出页面在另一个tab上打开。这个用户输入的个人信息就能被代理在不可见iframe上的脚本很简单的获取到。另外，代理可以假扮登陆用户发布任意订单。我们相信这是一个浏览器的一个重大缺陷：只要HPIHSL导入脚本或样式表（通常使用HTTP），HTTPS域就很容易被入侵。

To get a sense about the pervasiveness of vulnerable websites, one of the authors of this paper used HTTPS to visit HPIHSL pages for a few hours. Table I shows twelve websites that we confirmed vulnerable (the exact names of the websites are obfuscated). Each row also shows the problematic HPIHSL page and the domain of the imported script. The vulnerable websites covered a wide range of services such as online shopping, banking, credit card, open source projects management, academic information, and certificate issuance. In particular, even the homepage domain of a leading certificate authority was affected. It is a reasonable concern that many websites simultaneously opening HTTP and HTTPS ports are vulnerable.

为了能对普遍存在的网站漏洞有一个感知，本论文的一个作者花了几个小时来使用HTTPS访问HPIHSL网页。表1现实了12个我们认为有漏洞的网站（网站的真实名字做了匿名处理）。每一行现实了有问题的HPIHSL网页和导入脚本的域。这些漏洞网站覆盖了广泛的服务类型，例如在线商店，银行，信用卡，开源项目管理，学术信息，证书发行机构。特别的，一个领导性的证书颁发机构的首页也受了影响。有理由担心很多同时使用了HTTP和HTTPS的网站有漏洞。

We will discuss in Section VII how our finding is related to a paper by Jackson and Barth [7].

我们会在第七部分讨论我们的发现是如何和Jackson和Barth写的论文联系起来的。【7】

【7】Collin Jackson and Adam Barth, “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks,” in Proceedings of the 17th International World Wide Web Conference (WWW2008)