I’d like to find out what session ID hijacking protection is built into the current version of ASP.NET.
I recently saw this very informative article that explains how session security can be enhanced by implementing an additional layer that encodes the IP address and user agent header into the session id. These details are then verified on each subsequent request.
It seems that this article was written for ASP.NET 1.1 so I’d like to know if anything similar is now built into ASP.NET. Is it still of any benefit to implement such an additional layer?
Thanks.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Check out this snippet from the Session Overview documentation:
System.Web.SessionState.HttpSessionState.SessionID values are sent in clear text, whether as a cookie or as part of the URL. A malicious user could get access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID value.
http://msdn.microsoft.com/en-us/library/ms178581.aspx
It seems to me that this means that there is no security baked into Session, so you probably shouldn’t use Session as a security measure. Instead, I would recommend relying on ASP.NET security (authentication, authorization).
Here is an article from the Patterns & Practices group on general security recommendations for ASP.NET.
http://msdn.microsoft.com/en-us/library/ff649100.aspx
Method 2
Hey, I have also been looking for ways to reduce the risk of session ID hijacking. I read Jeff Prosise’s article as well and I thought it could be useful; however, just like you, I was looking to see if the same approach applies for modern versions of the framework (his email [email protected] doesn’t work btw)
jkohlhepp, I don’t agree with your post (or maybe I don’t understand it):
you probably shouldn’t use Session as a security measure. Instead, I would recommend relying on ASP.NET security (authentication, authorization)
As far as I’m concern asp.net authentication relies on Session IDs (except cookieless which seems to be worse: See Dino Esposito’s opinion)
So, that pretty much put us where we started.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0