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)