Session Hijacking Protection in ASP.NET

2019-02-09 12:22发布

问题:

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.

回答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



回答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 wicked@microsoft.com 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.