Mitigating the 'firesheep' attack at the network layer?

Solution 1:

As long as session data is passed in the clear between server and client, you are vulnerable to some kind of hijacking on unsecured networks. The stateless nature of HTTP pretty much guarantees that anyone with your session data can pretend to be you to the server.

So what to do? You need to securely pass session information from server to client, without eavesdroppers being able to intercept it. The surest, easiest way is to make your site all HTTPS, i.e. no unencrypted traffic. This is very easy to implement, as you don't have to change your application, only the servers. The downside is that it increases the load on your servers.

If that's not an option, then you need to somehow obfuscate the session data that the server passes to the client. And the client needs some scripting to "de-obfuscate" the session data to pass back to the server on the next request. Yes, this is "security through obscurity", and everybody knows that it doesn't work. Except when it does. So long as your site is not a high value target, obscuring the session data will prevent casual users of this 'firesheep' thing from hijacking your users. Only when/if your site gets on the radar of someone willing to reverse-engineer your obfuscation will this mitigation technique fail.

Solution 2:

Why would you have to encrypt the entire site?
Just set up a subdomain, login.yourcompany.com, encrypt that bit, set the secure flag on the cookie (stops it being passed over anything other than a secure channel), and set up the login server with an internal trust (however you want to do this is up to you) to the rest of the application.

Solution 3:

See Ben Adida's proposal/code for "SessionLock Lite". It admittedly offers no protection against active attacks or eavesdropping and is vulnerable to short-lived attacks. But it might help in the immediate term while you engineer a real SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/