Implications of the security model of HTTP cookies on HTTPS connections

Question

I have a feature that would require the user being able to provide the URL for a custom script, store the URL in a cookie, and incorporate the script into subsequent responses.

This, of course, immediately raises concerns over possibilities of a cross-site scripting attack, but using HTTP, given that no third-party can manipulate the cookies* unless performing a man-in-the-middle attack, at which point it is easier to directly inject scripts into the page, this does not further compromise the integrity of the site.

* assuming all ports of all subdomains of the originating domain are trusted, since cookies do not fall under normal same origin regulation

Using HTTPS, however, one would expect that, using appropriate encryption and certification, like any other part of the communication, the cookies can be trusted to come from the user, either by setting indirectly through the server or directly through a dedicated user agent interface, eliminating the risk of a man-in-the-middle.

Turns out, this is not the case, since browsers can be instructed not to send cookies set through secure channels on unsecure channels (using the secure attribute), but they readily send cookies obtained through unsecure channels on secure channels.

So, for example, an attacker, diverting traffic around a wireless access point, could lure a victim into requesting a page in the given domain through HTTP (by clicking a link, displaying an embedded resource like an image, or redirecting to it), respond with a forged cookie, and have the victim use the forged cookie while communicating with the server using HTTPS (injecting a malicious script, fixating her session etc.).

Considering all these, I have several questions:

1. Is the above understanding correct, and should a server communicating with the client through HTTPS consider all cookies to be possibly compromised, only using them in a way which prevents compromising the security of the site (allowing only a selection of trusted predefined scripts, regenerating the session id, etc.)?

2. Is there any way given the available framework of HTTP to ensure the integrity of cookies when using a secure connection I haven’t thought of? (Perhaps using cryptography?)

3. Is there any standardization effort ongoing to solve this problem, that I just haven’t heard of? If not, how come browser vendors, who go out of there way to apply the same origin policy wherever they can and alert users to the risks of mixed content, do not address this weakness in the protocol?

Answer 1

Generally speaking, a server shall consider every incoming data element as being potentially hostile. There is, here, a definition issue when you talk about "site integrity": this can be about integrity of the site as the user sees it, or the integrity of the site as other users see it. If all the server does is to send back the cookie back to the client who said it, as a script to execute, then the problem is simpler.

---

As I understand it, you fear the following scenario:

• The site allows a user U to upload some Javascript, that your server will "store" and serve back to the same user U. This uploading goes through a properly secured process (HTTPS, user authentication...). The storage is not actually done in the server, but as a cookie value in the user's own browser.

• By exploiting the user's gullibility, or hijacking the user's network access, the attacker succeeds in pushing some hostile Javascript H into the user's browser, attached (as a cookie value) to your server name.

• When the user U next connects to your server, the hostile Javascript H is sent to your server (as a coookie) and the server sends it back to the client, to be executed.

Described that way, then your problem really is one of recognizing "official" cookies that have been pushed to your server through the normal process (with HTTPS and user authentication). Cryptography can help, with a MAC: you want to tag a cookie value, such that only your server can compute a proper tag, and can verify it. That way, your server would reject cookie values that have not been previously recorded through the secured registration process. In the scenario above, the hostile Javascript H value would lack a proper MAC value (because the attacker does not know the MAC key used by the server), so the server would refuse to send back the cookie contents as a script to execute.

In all generality, what you are trying to do is to offload server state onto clients. This can be done with:

• a MAC to preserve integrity (against clients who modify their cookies, willingly or not);
• encryption, if the state contents must not be shown to the user (this does not apply to your specific case, as you describe it).

See this question for some details.

Take care that the size of an individual cookie, and the number of cookies recorded by a browser for a given site, are both subject to browser-specific limitations.

Answer 2

Yes, your understanding is correct.

Short answer - set a HSTS Policy (HTTP Strict Transport Security). Once this is set per browser instance, any plain HTTP connection made by the browser will automatically be upgraded to HTTPS.

Note that this only takes effect after the first visit, when the HSTS HTTP header is received over HTTPS. To guard against any attacks setting the cookie before their first visit from a browser, you can apply to have your domain listed in the HSTS Preload. This list is included in builds by major browser vendors, and doesn't require a first visit to a domain to enable HSTS for any preloaded domains.

Using HSTS Preload means that every subdomain on your site will need to use HTTPS - this is good practise anyway, because as you noted the Same Origin Policy for cookies is not very strict when it comes to domains.

The above approach will prevent a Man-In-The-Middle from injecting cookies into your site by intercepting any plain HTTP request and redirecting it to your domain, and will prevent subdomain attacks.

The flow with HSTS

Without preload

First HTTP visit --> Server redirects to HTTPS --> HSTS Set
--> Cookie containing JavaScript set

Next HTTP Visit | browser upgrades to HTTPS --> Safe JavaScript in cookie runs

With HSTS preload

First HTTP visit | browser upgrades to HTTPS --> ...

Any attacker redirecting the user by a MITM attack

Without HSTS

User requests a plain HTTP site --> HTTP 3xx redirect to your site --> Evil cookie set over plain HTTP
User requests your site over HTTP --> Server redirects to HTTPS --> Malicious JavaScript is ran

With HSTS

User requests a plain HTTP site --> HTTP 3xx redirect to your site | browser upgrades connection to HTTPS --> Attack thwarted as attacker cannot MITM the HTTPS connection

Even with Secure cookies, the server cannot query the fact that the secure flag has been set - all the server gets is the name/value pair. Therefore, there is no way to know that the cookie has been poisoned. HSTS is an effective solution because this cuts off the insecure, plain HTTP channel.

_{Note that the questions says that a URL is stored in the cookie not direct JavaScript - however including JS code from a third party domain has exactly the same effect - the code runs in the origin of the requesting domain}

If you need plain HTTP support

The reason you need HSTS is because the Same Origin Policy for cookies is more lax than those of the DOM and during AJAX requests:

cookies have scoping mechanisms that are broader and essentially incompatible with same-origin policy rules (e.g., as noted, no ability to restrict cookies to a specific host or protocol) - sometimes undoing some content security compartmentalization mechanisms that would otherwise be possible under DOM rules.

Therefore only way to protect your cookie containing JS code securely is to have plain HTTP support only on a completely different domain. e.g. https://example.org with HTTPS and HSTS for your secure content and the cookie, and http://example.com for your non-secure content.

An alternative to cookies

If you cannot do the above, the why not use HTML5 Session Storage instead of cookies, and only set or read the value over HTTPS? This method will allow you to store the JavaScript URL in the browser and run it as needed, without the possibility of a MITM intercepting and modifying the value over plain HTTP:

separation means that a value saved to LocalStorage on http://htmlui.com cannot be accessed by pages served from https://htmlui.com (and vice versa). [*]