Is HTTPS the only defense against Session Hijacking in an open network?

views:

287

answers:

+21 Q:

Is HTTPS the only defense against Session Hijacking in an open network?

So with Firesheep, everyone in a public Wi-Fi now has a one-click session hijack tool.

The way it works - to my understanding - is that it simply captures all traffic and grabs the session cookie (so it doesn't steal passwords).

From my understanding, this also means that a HTTPS secured login does not solve this alone, as further HTTP traffic would include the Session Cookie in clear text again.

Tying the session to a specific IP address is useless thanks to NAT, and tying it to the user agent is easy to spoof.

So is 100% HTTPS at all times the only way to prevent this type of session hijacking? Couldn't people simply sniff the entire HTTPS Traffic including the handshake, or is this stuff safe? (I'm thinking of replay attacks, but have no knowledge in that area.)

Of course, not using public/open Wi-Fi Networks is the better choice, but I'm still interested what a website developer can do to protect his/her users.

+11 A:

Firesheep is nothing new. Session hijacking has been around for as long as web applications have been using Session IDs. Usually hackers just set their own cookie by typing this into the address bar: javascript:document.cookie='SOME_COOKIE'. This tool is for script kiddies that fear 1 line of JavaScript.

Cookies can be hijacked if you don't use HTTPS for the entire life of the session and this is a part of OWASP A9 - Insufficient Transport Layer Protection. But you can also hijack a session with XSS.

1) Use httponly cookies.

2) Use "secure cookies" (Horrible name, but it's a flag that forces the browser to make the cookie HTTPS only.)

3) Scan your web application for XSS using Acunetix (free) or wapiti (open source).

Also don't forget about CSRF! (Which Firesheep doesn't address.)

Rook 2010-10-25 18:04:17

"this tool is for script kiddies that fear 1 line of JavaScript." haha +1 as soon as I can vote again

KennyCason 2010-10-25 18:21:49

No, this tool is for dumb executives that need to be shown that *anyone* can hack their precious site.

Konrad Rudolph 2010-10-25 18:29:09

http session hijacking has been going on for more than two decades? Really?

splattne 2010-10-25 18:45:07

Indeed, Session Hijacking is old, but it is still seen as a theoretical issue. Especially since having 100% HTTPS is quite expensive (Certs and Increased Server load) it's often neglected. Hence wondering if it's the only possibility - seems so, as Secure Cookies expect to run on HTTPS and HttpOnly doesn't help at all if you intercept at a network level.

Michael Stum 2010-10-25 19:22:10

The first browser to support cookies was (according to wikipedia) netscape .9 beta (october 1994). "Two decades" is probably pushing the timeline a bit ...

telent 2010-10-25 20:05:45

HTTP Session hijacking also can be used against session ID's in query parameters.

Darron 2010-10-25 20:43:35

@Michael Stum a ssl handshake is cached. HTTPS is very cheap and is the only way to provide a secure session for your users. (Period end of story.)

Rook 2010-10-25 20:53:23

@telent yes i agree with Darron, session id's where transmitted via GET before cookies. Sessions are as old as web applications, so probably more than 2 decades.

Rook 2010-10-25 20:54:13

It's 2010. Two decades ago it was 1990. I am prepared to bet that there were not many web applications in 1990 whose users were at risk of being sniffed on open wireless networks. The 802.11b standard only appeared in 1999, after all

telent 2010-10-26 12:18:33

I'm not disputing that the potential exists, but to dismiss Firesheep as "nothing new" is to neglect the social and PR aspects of its release more than slightly. Now we can get managers to *agree* it's a real risk, at last - isn't that something new?

telent 2010-10-26 12:20:34

@telent: Cue the wave of denial in 3...2...1... (Real Story: Many moons ago, I was tasked to "check for security issues;" I found several, wrote a simple and scary proof-of-concept, the execs' reaction was "Nah, who would want to hack us? We need more cowbell instead." Then one day, a normal user incidentally typed `150;` instead of `150` into a form and deleted all their records for the day (seriously!). Some security fixes were allowed after that. Luckily, I no longer work there)

Piskvor 2010-10-26 12:52:12

@telent: On the other hand, two decades ago, most people on an Ethernet network would not be connected through layer-2 switches, but using a shared medium - e.g. a BNC coax, or 10BaseT with hubs. So, like with open wireless, each computer could see all traffic on that network segment. Basically the same issue on a different physical medium.

Piskvor 2010-10-26 13:06:56

I'm not sure if the 'two decades ago' remark is worth that much discussion :) It's been around for _ages_, that's true. FireSheep is an old concept, but it's a high visibility tool that now makes session hijacking available to your mom, not just to script kiddies anymore. Also, it shows again that WLAN (which works like a Hub rather than a Switch) is absolutely insecure, no matter what. Hence my question, because for my next web app I'd really like to avoid this :)

Michael Stum 2010-10-26 17:43:30

@Michael Stum your right about the whole 2 decades nonsense, i changed my post. As an application developer I am not too concerned with unskilled attackers. This attack is trivial to defend against from the application's preservative, just set a few cookie flags. On a side note I am happy to see that people are taking OWASP A9 more seriously.

Rook 2010-10-26 18:08:44

+8 A:

The Rook has answered some of it, I'll just answer the other parts of your question.

Is 100% HTTPS at all times the only way to prevent this type of session hijacking?

That's right. 100% HTTPS is the only way. And 100% is key.

Couldn't people simply sniff the entire HTTPS Traffic including the handshake, or is this stuff safe? (I'm thinking of replay attacks, but have no knowledge in that area)

HTTPS has built-in protection against replay attacks. If implemented correctly, HTTPS is truly safe.

Even if HTTPS is implemented correctly, there are ways to get around it. SSL Strip is one such tool. The tool doesn't exploit SSL, it just exploits the fact that people always type mybank.com in the url instead of https://mybank.com.

sri 2010-10-25 20:26:44

+1 for ssl strip. Although i thought it was obvious that https must be used 100% of the time. Oah well.

Rook 2010-10-25 20:55:31

ansaurus

tags:

views:

answers:

Is HTTPS the only defense against Session Hijacking in an open network?

related questions