Avoiding session hijacking in ASP.NET

Question

I recently read an article on making ASP.NET sessions more secure here and at first it seems really useful.

Previously I had been storing the user's IP address in the session, then making sure in every subsequent request that the requesting IP was equal to the stored IP.

The code in the article also protects the session by checking the IP address, except it stores a hashed message authentication code containing the user's IP as part of the session cookie. It creates a hashed MAC twice every request, which I imagine would slow things down a little.

I can already see a potential flaw in their code: if you were to somehow get a hold of the key used to generate the MAC, you could then generate a valid MAC with your own IP - you wouldn't even have to fake the IP the session was started on.

It seems like an overly-complex solution to a simple problem which not only incurs a larger overhead but also is more susceptible to attack than the trivial method - unless I'm completely missing the point.

So, why would this approach be any more secure than the more simple approach that I had been using?

As a slight aside, the author also states that you shouldn't use the whole IP address in the comparison, as some user's IPs change every request if they are behind a proxy. Is this still the case if you check X_FORWARDED_FOR?

Thanks!

Ineslta

On a side note: be sure to avoid using cookieless sessions, as the session ID is stored right in the URL. – Unbosom

Really window dressing, since getting a session code from a cookie is trivial. But having long session IDs in a url is hideous anyway and causes other issues such as if people bookmark or share a link. – Lipography

Answer 1

See this post: What is the best way to prevent session hijacking?

Basically, you should use HTTPS on your login page and any other "sensitive areas".

Unbosom

+1.. given that any teenager can brainlessly steal sessions from people in a coffeshop with this: news.softpedia.com/news/… ... if you care, this is the only way. Actually end-to-end https is the only way to protect against this kind of attack. And you should still use encrypted or long/random codes to identify a session. – Lipography

Thanks. I know that ideally you should use HTTPS, but my question still stands: why did they go to all that bother with the MACs if it isn't even as good as the easy way? – Ineslta

I'm marking this as an answer - basically it seems that any way to do it is not as good as your suggested method, so my question doesn't really matter. – Ineslta