PBP: IV. STATIC-HTML-BASED PBP EXPLOITS

IV. STATIC-HTML-BASED PBP EXPLOITS

We just described a number of script-based attacks that violate the same-origin policy. By running malicious scripts in the context of victim HTTPS domains, these attacks can access or alter sensitive data that are supposed to be protected by HTTPS.

Nevertheless, in order to better understand the potential threat of PBP, thinking beyond script-based attacks is very important. Typically, for script-based security issues, the defense solutions are along the line of disabling, filtering, or guarding scripts. When a class of security problems is not always script-related, defense solutions should be explored more broadly. 

In this section, we show two attacks that can be accomplished entirely by static HTML contents. They target the authentication mechanisms in browsers. In the first attack, the proxy’s own page can be certified with the trusted certificate of the HTTPS server that the browser intends to communicate. In the second attack, the proxy can authenticate to the HTTPS server as a logon user.

A. Certifying a Proxy Page with a Real Certificate

In Section III.A, we have seen that the PBP proxy can supply a script in an error-response. The script will run in the HTTPS context of the victim server and compromise the confidentiality. When we reported this issue to a browser vendor, one of the vendor’s proposed fixes was to disable scripts in any 4xx/5xx error-response pages, and only render static HTML contents. The proposal was based on the consideration that benign proxy error messages are valuable for troubleshooting network problems, but there is no compelling reason to allow scripts in error messages.

This fix would not block the attack that we describe below, which does not involve any script. Figure 4 illustrates how a proxy certifies a fake login page by taking advantage of a cached certificate of https://www. paypal.com from a previous SSL handshake. (Note that it is a browser bug. PayPal represents an arbitrary website.) IE, Opera and Chrome, but not Firefox, are vulnerable to this attack. (Note that Safari always displays the lock icon when the address bar has an HTTPS URL, even without a cached certificate, so Safari is a trivial target of the spoofing attack.)

The attack works as follows: when a browser issues a request for https://www.paypal.com (step 1), the proxy returns an HTTP 502 message (or any other 4xx/5xx message) that contains a meta element and an img element (step 2). The meta element will redirect the browser to https://www.paypal.com after one second. But before the redirection, the following steps happen subsequently: the img element requests an image from https://www.paypal.com/a.jpg (step 3). In order to get a.jpg, the browser initiates an SSL handshake with the HTTPS server. The request is permitted by the proxy at this time. After the browser receives a legitimate certificate from the HTTPS server (step 4), it will try to retrieve a.jpg, which may or may not exist on the server (not shown in the figure). But its existence is not important here because the purpose of the img element is to acquire a legitimate certificate, which has been cached in the browser now. The certificate cache is designed to enhance the performance of HTTPS by avoiding repetitive re-validation for each SSL session.

When the one-second timer is expired, the browser will be redirected to https://www.paypal.com (step 5). This time, the proxy returns another HTTP 502 message (or any other 4xx/5xx message) that contains a fake login page (step 6). When the browser renders this page, it picks up the cached certificate of PayPal and displays it on the address bar as if the fake page was retrieved from the real https://www.paypal.com.

While the attack described here and the one described in Section III.A both take advantage of the fact that browsers render proxy’s error messages in the context of HTTPS servers, these two attacks are distinguishable – In terms of the technique, this is a perfect GUI spoofing attack. Even when the user starts a fresh browser and uses a bookmark to access the HTTPS URL, he/she still gets the certified faked page. The attack is conducted in only one window and does not execute any script, therefore bypasses the pop-up blockers in today’s browsers that will otherwise thwart the spoofing attack. No other attack that we describe can achieve the same result. In terms of the root cause, the proxy-page-context problem in Section III.A alone does not necessarily enable this attack, e.g., we have confirmed that Firefox is not vulnerable to the attack although it has the problem in Section III.A. A key enabler of the GUI spoofing attack is the interaction between the graphic interface and the certificate cache: for IE, Opera and Chrome, the certificate is displayed as long as it is available in the cache.

B. Stealing Authentication Cookies of HTTPS Websites by Faking HTTP Requests

The attack in Section IV.A is to impersonate a legitimate HTTPS website. We now describe an attack that allows the PBP to impersonate victim users to access HTTPS servers by stealing their cookies.

Cookies are pieces of text that browsers receive from web servers and store locally. They are used to maintain the states of HTTP transactions, such as items in consumer’s shopping carts and personalized settings of user webpages. In addition, they are used as an important mechanism for web servers to authenticate individual users. After a user successfully logs on a server, the server sends some cookies to be stored in the user’s browser, which uniquely identify the session between the server and the user. Next time when the user accesses the server, these cookies are presented to the server as a proof of the identity of the user.

Browsers use the same-origin policy to determine whether cookies can be attached to requests or accessed by scripts. The policy specifies that: 1) Cookies of a domain can only be attached to the requests to the same domain; 2) Cookies of a domain are only accessible to scripts that run in the context of the same domain. However, unlike the same-origin policy of script and DOM, the same-origin policy of cookies does not make a distinction between HTTP and HTTPS by default. In the default scenario, cookies of http://a.com may be accessed by pages or scripts of https://a.com, and vice versa. Optionally, a SECURE attribute [5] can be set to ensure that cookies can only be read by pages in the HTTPS context and be attached to the HTTPS requests (of course, after the SSL handshake).

We found that many websites do not set the SECURE attribute for cookies that identify HTTPS sessions2. As an example, an author of the paper investigated about 30 websites in which he owns an account. About one-third of the websites used cookies for authentication but did not set the SECURE attribute for them. Every website was verified individually to show that the stolen cookie was sufficient to allow the attacker to get into the logon session from an arbitrary machine and to perform arbitrary operations onbehalf of the victim user. These nine websites are listed in Table II, with their names and URLs obfuscated. They cover a wide range of services such as stock broker, online shopping, online banking, academic paper reviewing, email service, mortgage payment, utility billing, government service, and traveling. They affect many different aspects of a person’s online security.

It is straightforward to launch the attack: the proxy waits until the user logs into the server (usually after seeing a few CONNECT requests), e.g., the stock trading website https://trading.StockTrader.com. After that, once the browser requests any HTTP page (including a page requested from another browser tab or any tool bar), the proxy embeds an iframe of http://trading.StockTrader.com in the HTTP response. When the browser renders the iframe, it makes an HTTP request for http://trading.StockTrader.com, exposing the authentication cookie in plain text to the proxy.

Given that a significant fraction (one-third) of the HTTPS websites that we examined have this problem and many of them are reputable, we believe this vulnerability exists in many other HTTPS websites as well. Although it is possible that inexperienced developers do not have knowledge about the SECURE attribute of cookies, the fact that reputable websites also make this mistake suggests that the concept of the SECURE attribute is commonly misconceived. The SECURE attribute is often vaguely defined as a mechanism to prevent malicious HTTP pages. It is never made clear that when the network is assumed untrusted, the SECURE attribute should be considered as a mechanism to prevent malicious proxies and routers. Without this clear interpretation, a developer might have a misconception: my HTTP pages are very secure (or “my website does not run HTTP at all”). Why bother to prevent my own HTTP pages from stealing cookies of the HTTPS sessions on my website?