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)