Is HTTPS the only defense against Session Hijackin

问题:

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.

回答1:

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.

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

回答2:

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.

回答3:

I do beleive SSL is cheap and a complete solution. But till you dont have it or looking for some extra layers here is how to protect your SESSIOn data.

As always defence in dept is the way to go. 1st Use Sessions to store user login data 2nd If admin logged in also check for DB, might slows a little but as there is a small number of admins and rest are users this is a feasible security plus. 3rd PROTECT YOUR SESSION <= !

Session protection: Put session start into an object file where you call an "is_session_valid()" function on self construct. This function would check for (IP / TIME / Browser) for $_SERVER superglobal, and store them in session. Up on Next load see if values are the same if not just waste no more resources logout user and show index page.

This is not a complete solution as it might be same browser on same network e.g. Wifi with lot of users and session hijacked might also be recent (in time). But till no SSL is used this is FAR BETTER then nothing. Anyhow rarely happens that the victim and the hijacker use same everything....so this effectively mitigates chances of successfull attack even without any SSL!

Original idea by Kevin Skoglund if ineterested in securing your APP see his secure PHP tutorial. https://www.lynda.com/PHP-tutorials/Creating-Secure-PHP-Websites/133321-2.html

P.S. Several other defenses (CSRF least) needs to be used to have a somewhat secure AP

Bye :-)