23/07/2014

Second Line of Defense in Web Applications Part 5 Mixed Content and Secure Cookies

About Mixed Content

When delivering HTTPS pages, web applications usually include some non HTTPS resources this is called mixed content. Browsers differentiate between active and passive content. Active content is content that has access to the DOM, such as JavaScript or HTML (which is essentially the DOM) and passive content, which cannot change the DOM, such as images. If an attacker can modify active content that is sent over HTTP, he has essentially created a XSS vulnerability and can read everything that is accessible via the DOM (which is a lot). Many modern browsers will block active mixed content for this reason. You can also use CSP to block and report any use of active mixed content.

This is a defensive mechanisms that requires no work on the side of the web application developer, as it is enforced only by the browser without any HTTP header or so. Although you could produce a broken website if you rely on including active mixed content. To fix this in a web application you can use protocol relative URLs or relative URLs in general. An example for a protocol relative URL would be:

<a href="//example.com/whatever" />

In this example “http:” was omitted, so the browser will use HTTP or HTTPS to load the resource depending on how the current pages has been loaded. If you use HSTS you will not run into trouble with mixed content, since HSTS forces all other resources to be loaded over HTTPS.

Secure Cookies

Session cookies are a popular target. Also man-in-the-middle attackers try to steal session cookies. Even if the authentication is secured with TLS, if the rest of the communication goes over HTTP the attacker can simply read the session id and use it to impersonate the user. But let’s assume a web application is serving all pages over HTTPS. If passive mixed content, like images, are requested from the web server, the session cookie will be leaked over a insecure channel. This is a very common scenario to limit the performance impact of using HTTPS.

The solution is the “Secure” flag for cookies. This flag instructs the browser not to send the cookie over and insecure HTTP connection, but only over HTTPS. This effectively prevents such leaks.

The two defensive mechanisms we discussed today are simple improvements that limit the possibility of accidentally leaking any information or creating a vulnerability when the web application is not carefully developed.