Session security and Chrome Frame

I've run into the nasty problem that Chrome Frame causes to session handling code that uses the user agent in its security. There are applications that use the user agent string in a hash that sets the signature of a session. Each time the session is loaded using that key, the signature is checked. This catches some session hijacking attempts. Let's assume that an attacker is able to obtain a user's session key and then uses it. There is some probability that the user agent will be different and the attack will fail. It's a layers of security approach - it doesn't prevent the attack but makes it harder. Of course, if the attacker sniffed the session key, the attacker also has the user agent. If the attacker obtain the session key from the user's computer, the user agent was available there also. So you can see that it is not much of a security feature.

There are web applications that use this and this is where Google's Chrome Frame browser addon for IE comes into play. This extension changes the user agent based on the type of data requested and the method of the request. These user agent changes result in the signature check to fail and the session is regenerated (and the user is logged out). Depending on the site and content, this can appear to be almost random or it can be very consistent (log in, log out, log in, log out...).

The solutions are to either drop this security feature or filter the chromeframe string out of the user agent.

2 Comments

I've run into this issue before as well while developing an Elgg site. My team discovered that adding the line:

<meta http-equiv="X-UA-Compatible" content="chrome=1" />

into our headers for each page stopped the log in, log out, log in, log out behavior.

We didn't drill deep enough to discover why ChromeFrame was causing the behavior once we found a way to stop it, but your explanation makes perfect sense. I suspect adding the meta line turns on ChromeFrame all the time, and thus the user agent string doesn't change.

We've seen this issue on some other intranet sites so there are other applications doing this besides Elgg. Of course, most of our apps are run over SSL so session hijacking through sniffing is not much of an issue.

For Elgg, I'm hoping to have a solution in core for the 1.7.2 release.

Leave a comment

Recent Entries

  • Building a Web Services API with Elgg

    Elgg provides an API for building custom web services. You expose functionality through the web services API by building a plugin and then either publish...

  • Session security and Chrome Frame

    I've run into the nasty problem that Chrome Frame causes to session handling code that uses the user agent in its security. There are applications...

  • Piwik and Elgg

    While Google Analytics may be the most popular analytics service, there are times when you want to use your own hosted solution (intranet, control over...

  • Piwik and Reverse Proxy

    Piwik generates its URLs used in links and forms based on data in $_SERVER[]. If you are using a reverse proxy in front of your...

  • Elgg Unit Tests

    A new component in Elgg 1.7 will be a unit test framework (SimpleTest). I've written a skeleton example of how plugin authors can use the...

Close