Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

What are the sysadmin's thoughts on mitigating the 'firesheep' attack for servers they manage?

Firesheep is a new firefox extension that allows anyone who installs it to sidejack session it can discover. It does it's discovery by sniffing packets on the network and looking for session cookies from known sites. It is relatively easy to write plugins for the extension to listen for cookies from additional sites.

From a systems/network perspective, we've discussed the possibility of encrypting the whole site, but this introduces additional load on servers and screws with site-indexing, assets and general performance.

One option we've investigated is to use our firewalls to do SSL Offload, but as I mentioned earlier, this would require all of the site to be encrypted.

What's the general thoughts on protecting against this attack vector?

I've asked a similar question on StackOverflow, however, it would be interesting to see what the systems engineers thought.

share|improve this question
2  
All your site content doesn't need to be encrypted. You should be serving your images and static content from another domain, anyway, to avoid the overhead of sending cookies along with each static asset request (see blog.stackoverflow.com/2009/08/a-few-speed-improvements for background). –  Evan Anderson Oct 27 '10 at 16:19

5 Answers 5

Credentials should always be encrypted, never passed in the clear. What's so hard about that?

share|improve this answer
    
The credentials for login aren't sent in the clear. The cookies, however, after being logged in, are not. –  pobk Oct 25 '10 at 17:47
1  
Aha, the first article I had found on Firesheep mischaracterized the problem. You could have added some details to your question. Firesheep is new enough that I don't even see it on Wikipedia, so the specific vulnerabilities would be worth enumerating in your question. –  mfinni Oct 25 '10 at 17:54
1  
@pobk: The cookie is acting as a proxy for credentials. If the cookie can be used to impersonate the user then it's a credential. –  Evan Anderson Oct 27 '10 at 16:18

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.

share|improve this answer
    
Well, user personalisation that happens on the site doesn't work then since the session is not available to the main site. –  pobk Oct 25 '10 at 17:50
    
Why? Ever heard of memcached? Share your sessions between your application servers. –  Tom O'Connor Oct 25 '10 at 17:51
    
The problem is the cookies. The fact they're unencrypted means that someone can sidejack someone's session. Where they're stored is irrelevant. Once they're sent in the clear, they're vulnerable to being sniffed. The reason it's a problem now, is that anyone who can install a firefox extension (pretty much everyone) can now do the sniffing. –  pobk Oct 25 '10 at 17:59
    
Assuming they're on an unsecured network. –  mfinni Oct 25 '10 at 18:02
1  
But you can't protect the unencrypted bulk of the traffic over www.xyz.com from a MITM, so an active attacker can arbitrarily mess with it, to say nothing of passively snooping on it. And how do you deal with valid browser complaints of mixed https/http content? –  nealmcb Dec 24 '10 at 21:39

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.

share|improve this answer
3  
I really want to upvote you but I can't get behind "security by obscurity" at all. Rather than thinking about this in terms of "security by obscurity" why not consider that a 2nd tier solution (if a site can't handle doing HTTPS) would be to use HTTP digest authentication rather than forms-based authentication with session cookies. It's still vulnerable to MiTM attacks and TCP-level hijacking but, at least, no credentials cross the wire (air) in the clear and third-party attackers can't heist your credentials. –  Evan Anderson Oct 27 '10 at 16:16
    
+1 @Evan: I completely forgot about HTTP digest auth. Being a cryptographic protocol that securely shares secret state between client and server, it is a better solution than any stateless security-through-obscurity obfuscation kluge. –  Steven Monday Oct 27 '10 at 19:13

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/

share|improve this answer

From a local admin perspective:

In order for firesheep to work on a wired network, the attacker would have to perform ARP poisoning on your switch infrastructure. Traffic to and from other computers will never reach the attackers PC, unless they first exploit the network.

From a service provider perspective:

I would want my site, or at least any auth or cookie traffic to be SSL encrypted.

From an end user perspective:

I would want the provider to keep my session safe, so I don't even have to think about typing in "https://". It should force me to be safe.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.