views:

2573

answers:

7

Specifically this is regarding when using a client session cookie to identify a session on the server.

Is the best answer to use SSL/HTTPS encryption for the entire web site, and you have the best guarantee that no man in the middle attacks will be able to sniff an existing client session cookie?

And perhaps second best to use some sort of encryption on the session value itself that is stored in your session cookie?

If a malicious user has physical access to a machine, they can still look at the filesystem to retrieve a valid session cookie and use that to hijack a session?

A: 

To reduce the risk you can also associate the originating IP with the session. That way an attacker has to be within the same private network to be able to use the session.

Checking referer headers can also be an option but those are more easily spoofed.

Julio César
Olaf
Sembiance
+6  A: 

Encrypting the session value will have zero effect. The session cookie is already an arbitrary value, encrypting it will just generate another arbitrary value that can be sniffed.

The only real solution is HTTPS. If you don't want to do SSL on your whole site (maybe you have performance concerns), you might be able to get away with only SSL protecting the sensitive areas. To do that, first make sure your login page is HTTPS. When a user logs in, set a secure cookie (meaning the browser will only transmit it over an SSL link) in addition to the regular session cookie. Then, when a user visits one of your "sensitive" areas, redirect them to HTTPS, and check for the presence of that secure cookie. A real user will have it, a session hijacker will not.

Josh Hinman
A: 

The SSL only helps with sniffing attacks. If an attacker has access to your machine I will assume they can copy your secure cookie too.

At the very least, make sure old cookies lose their value after a while. Even a successful hijaking attack will be thwarted when the cookie stops working. If the user has a cookie from a session that logged in more than a month ago, make them reenter their password. Make sure that whenever a user clicks on your site's "log out" link, that the old session UUID can never be used again.

I'm not sure if this idea will work but here goes: Add a serial number into your session cookie, maybe a string like this:

SessionUUID, Serial Num, Current Date/Time

Encrypt this string and use it as your session cookie. Regularly change the serial num - maybe when the cookie is 5 minutes old and then reissue the cookie. You could even reissue it on every page view if you wanted to. On the server side, keep a record of the last serial num you've issued for that session. If someone ever sends a cookie with the wrong serial number it means that an attacker may be using a cookie they intercepted earlier so invalidate the session UUID and ask the user to reenter their password and then reissue a new cookie.

Remember that your user may have more than one computer so they may have more than one active session. Don't do something that forces them to log in again every time they switch between computers.

A: 

Ensure you don't use incremting integers for session IDs. Much better to use a GUID, or some other long randomly generated character string.

Kibbee
A: 

Try Secure Cookie protocol described here

As stated in document:

A secure cookie protocol that runs between a client and a server needs to provide the following four services: authenti- cation, condentiality, integrity and anti-replay.

As for ease of deployment:

In terms of efciency, our protocol does not involve any database lookup or public key cryptography. In terms of deployability, our protocol can be easily deployed on an existing web server, and it does not require any change to the Internet cookie specication.

In short: it is secure, lightweight, works for me just great.

Hubert
Your link is a spec of the protocol - do you have a link to an implementation? That would be great - thanks.
Adam
A: 

Has anyone implemented this secure cookie protocol in Rails? I'm curious to see how it was done if so.

A: 

when creating session through the GET part of the URL is disabled by setting the parameter the ini file session.use_only_cookies=1, there is still one question that I couldn't find the answer: what if a user creates a cookie named PHPSESSID with a value as a session id, when the session_start() function is called does it create a session using the same id in the cookie PHPSESSID or it cannot????????????????????????????

bridggs