Friday, March 23, 2012

Why Echo360 Fails on Chrome

Here is the promised explanation of how and why a proxy is required to download lectures from UWA's Echo360 server when using Chrome.

In firefox, lectures can be downloaded simply by requesting the file "mediacontent.m4v".  Attempting to do the same in Chrome, however, gives us the following error:

Oh Noes!

If we actually look at the headers the server is sending us, the problem quickly becomes apparent:

The Content-Disposition Header is sent twice.  Chrome conservatively interprets this as a potential response splitting attack.

As you can see from the above screenshot, UWA's Echo360 server erroneously sends the Content-Disposition header twice.  Because of the non-standard response, Chrome will refuse the connection.  Why refuse the connection?  Well, from Chrome's perspective, the double header could be a symptom of a HTTP response splitting attack, so the connection is refused on security grounds.  In actuality, there is no security problem; simply put, the developers of Echo360 don't know how to write a web server (other users of Echo360 have reported the same issue, eg UniSA).  

Hence why it is necessary to use a proxy to download lectures when using Chrome (as described previously).  Instead of directly requesting "mediacontent.m4v" through Chrome, we send the request through to a locally running proxy server.  The proxy server will then download "mediacontent.m4v" from UWA's server, ignoring the double header (we can safely ignore it, because we know that the double header is the result of incompetence, not malice).  The proxy server will then send the contents of "mediacontent.m4v" through to the browser, but will actually set the HTTP headers correctly.

Although the proxy server ignores duplicate headers, this does not create a security problem.  The proxy server will only download data from UWA, where it is known that the duplicate headers are not a problem.

In any case the proxy server does not pass any headers through to the browser - it completely re-writes them.

It should be noted that there is no implication in the above that the software is completely invulnerable to all forms of response splitting (for example, an attacker could modify the contents of the downloaded file, and there is no way to detect that).  The only claim I make is that it is safe to ignore the duplicate header (a specific type of response splitting) in the limited set of circumstances I've outlined (downloading lectures from UWA's Echo360 server using the proxy I provided).  But realistically, you really shouldn't run into any security problems at all.


No comments:

Post a Comment