CODEWITHSUNDEEP
asp.netsession
Frank Thomas
Frank Thomas

Reputation: 2514

Seurity ramifications of ASP Session

I'm looking into storing some security sensitive information (a users effective permissions for our web application) in a session-resident object, to reduce database queries while performing permissions checks throughout the app.

I understand that the session is stored server-side, and not directly accessible to the client under normal circumstances. ASP.net's other persistence mechanisms can be theoretically defeated, by modifying viewstate or cookie values client-side, but these kinds of cryptography implementation flaws should not expose session-state.

What degree of control over your server would an attacker need to modify data in a clients session-state? Assume they have a sessionID, and an ASPAUTH cookie.

For instance:

I know these kinds of questions often rely on mistakes in my code, so by all means assume I've written the worst, most insecure code ever (I haven't, but...) and do things like change session in a constructor or life cycle event.

Upvotes: 0

Views: 50

Answers (2)

Learning
Learning

Reputation: 20001

Session variable can be a security risk. It is always better to secure your session variable.

Few links you should take into consideration...

Securing Session State http://msdn.microsoft.com/en-us/library/ms178201%28v=vs.140%29.aspx

http://www.dotnetnoob.com/2013/07/ramping-up-aspnet-session-security.html

http://www.codeproject.com/Articles/210993/Session-Fixation-vulnerability-in-ASP-NET

http://www.dotnetfunda.com/articles/show/730/session-security-in-aspnet

I agree with Erik views.

regards

Upvotes: 1

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93444

Since we don't know exactly how your code is implemented, all we can do is guess.

First, Session should NEVER be used for security sensitive things. Yes, it's true that a client can't directly read session, there are other factors to consider.

  1. Session cookies are not, by default, encrypted and are passed as plain text.
  2. Session Fixation attacks are easy to accomplish
  3. If a session cookie is hijacked, or even guessed, then it doesn't matter what the users account is, they will get whatever security rights you assign via that cookie.
  4. Session is unstable, and IIS can kill sessions whenever it feels like, so you end up with the situation where a user is still logged in, but their session is lost due to many possible reasons. So now their security is also unstable.

There are many other, more appropriate ways to do what you want, Session is NEVER an appropriate method.

Other methods that would be appropriate include...

  • Using the user data field of a FormsAuthentication ticket to store the information
  • Using a custom Claim with a claims based authentication, like ASP.NET Identity, WIF, or IdentityServer.
  • Using the asp.net Cache to hold the temporary information, based on identity (not session) and adding a cache eviction timeout.
  • and many more...

Upvotes: 2

Related Questions