how to mitigate asp.net session security risks

Question

I understand that it is possible to hijack the asp.net session by stealing the asp.net session cookie. I guess that I'm thinking of stealing the cookie as it is transmitted over unsecure wi-fi.

Other than using SSL are there standard ways of securing this information? Or preventing the hijacking of the session?

Answer 1

Sadly, the only way to prevent cookies from being used in a replay attack is to send them over HTTPS since that ensures that the cookie itself is encrypted and, therefore, kept from prying eyes.

Have you seen Jeff Atwood's blog entry about this matter, Breaking the Web's Cookie Jar? Jeff focuses more on the concerns from the user's perspective, but it's worth reading anyway. Here's what he says folks can do today:

So here's what you can do to protect yourself, right now, today:

1. We should be very careful how we browse on unencrypted wireless networks.

2. Get in the habit of accessing your web mail through HTTPS.

3. Lobby the websites you use to offer HTTPS browsing.

This is very broad advice, and there are a whole host of technical caveats to the above. But it's a starting point toward evangelizing the risks and responsible use of open wireless networks.

There probably needs to be some sort of new, more secure approach for cookies going forward, but who knows if there will be enough traction to warrant such change or enough interest to spurn adoption. For web applications where security is paramount - think medical information websites, financial websites, and so on - the only plausible option is to require HTTS for the user's entire browsing session.

Answer 2

There is no easy solution to that problem, other than requiring the authentication information with every page request (which isn't practical and is worse from a security standpoint in an unencrypted environment).

In order to maintain state while using HTTP (which is stateless), something like a cookie must be used. If that cookie is being sent unencrypted, it can be used by somebody else.

As a side note, if you have to pick between two evils of having a session hijacked and having the password compromised, you would rather have the session hijacked. That is why it is crucial that changes like password modifications require re-authentication so that a hijacked session can't take over the account itself. Of course that can also be circumvented if the authentication credentials are not encrypted.