Click here to Skip to main content
15,067,335 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
Hi everyone,

relating to another question I asked:How define "Global" variables[^]

How secure/unsecure is to store security related information in session variables?

I'm not talking about username/password or similar, but, for example, about the "roles" a user belongs, or if he has specific permissions.

I would like to use the session variable approach to set the "security configuration" of the user at logon and reduce access to database for checking permission every time, but obvusly I won't do it if it causes a threat.

Different controls (check if user is autenticated for example) will be handled separatedly.

Is it possible for a user to arbitrarily alter the session variable values?

Additionally, how possible it is for a user to "steal" another session cookie and get access to "reserved" data?

Thank you in advance,

Alberto

[UPDATE]

To better explain the situation of the application:

Users belong to different "companies", and each company is an " isolated" environment (users of company A cannot see users and operations of company B)

That said, the users of a specific company can belong to one or more "Company Groups", and have other specific permissions, which are defined on a per-Company basis, and I find hard to use asp.net role membership to achieve this (administrators of company a must not see other companies' groups).

Currently, users authenticates to application using standard asp.net mebership provider, and checked to have required base asp.net roles.

After that, each time the user requests data to the database, I'd have to:

- check to which company the user belong
- check to which company roles the user belong
- ...so on for other specific user permissions
- finaly pull out only the data the user is allowed to see.

The idea is that of setting all the additional security information on session variables at log on. At each request, asp.net authentication will automatically check if user is authenticated, and I'll verify that session variables with additional security info are set.

So, if UserA is capable of stealing both asp.net authcookie and session state of UserB, he obvusly can access data as if was UserB, while if he can steal only one, theorically I'll have an additional level of security (for example, if UserA steals session from UserB, but there is no maching with authcookie, I can block the user).

The other probelm I must consider is: is there a way by which UserA can alter the session state variables manually, so that he could manually add roles and permission to his current session)?

Is the possible problems still effective on a full https application.

Thank tou agin,

Alberto
Posted
Updated 29-Nov-11 21:12pm
v2

I wouldn't do it. I would check the database ever time for the permissions. It is relatively easy for a user to steal the session state of another user.

Check out the links below for a better definition.
http://en.wikipedia.org/wiki/Session_hijacking https://www.owasp.org/index.php/Session_hijacking_attack

This should give you a better idea of how safe it is. You can put precautions in when checking the session to make it more secure. Like verifing the name for the computer using the session. It still can be hacked pretty easily though.

You should also check out these article for best practices for security with asp.net.
http://msdn.microsoft.com/en-us/library/ff649487.aspx#pagguidelines0001_sessionmanagement
http://msdn.microsoft.com/en-us/magazine/cc163730.aspx
http://msdn.microsoft.com/en-us/library/zdh19h94.aspx
   
v6
Comments
Alberto Biasiutti 30-Nov-11 2:46am
   
Thank you very much.. but isn't it as easy to steal the authorization cookie created by asp.net FormAuthentication?
GateKeeper22 30-Nov-11 8:07am
   
It is but all that shows is that the user is authenticated. I don't believe that the user name is stored in that cookie at all so you would still need to get the user name from HttpContext to check their roles with the Role Provider. The Role Provider always queries the database unless you have overridden it to check the session. If you are using HTTPS than it does make it more secure, the session is encrypted than. I would still avoid using the session to store any thing about Roles and Authentication as much as possible. Even with HTTPS users are still able to get the session and change values in it. Your database should be a lot more secure than your session. When dealing with sensitive information I always have it more secure even if it does cause a little of a performance hit. For a good article about this check out. http://msdn.microsoft.com/en-us/library/ff649487.aspx#pagguidelines0001_sessionmanagement.
Alberto Biasiutti 1-Dec-11 3:49am
   
Thank you again for answering.
I think that I'll take a quite different approach, but anyway I would like to clarify a thing (to better undertand how it works):
IF I'm not wrong, You said that the "crucial" part of "stealing" someone's identity is to access the httpContext and steal the user name. But, from what I understand, the session IS part of the httpContext (in fact, I access it via HttpContext.Current.Session["VariableName"])
Doesn't this technically put it at the same level of security (or vulnerability) of stealing the username?
GateKeeper22 1-Dec-11 8:39am
   
I am not 100% sure on this but I believe that the username in the httpContext comes from the http request. I am not talking about the httpRequest object I am talking about the actual information sent a crossed the line. So no it wouldn't put it at the same vulnerability.
Nothing on the web is truly secure. If it is valuable enough to a hacker they will find a way to get to it. That being said session state is reasonably secure, Microsoft has taken care of most of it and session shouldn't be a problem under normal circumstances.

You may want to look at this ASP.NET 2.0 Membership, Roles, Forms Authentication, and Security Resources[^]
   
Comments
GateKeeper22 29-Nov-11 14:29pm
   
For the article you suggest isn't all of that information stored in a SQL DB and not in the Session state? Correct me if I am wrong. That is how it has always been set up when I have used the Role provider.
[no name] 29-Nov-11 15:15pm
   
Yes that is correct. Do you have any metrics for performance? How do you know if one method is better or worse than another?
GateKeeper22 29-Nov-11 15:29pm
   
I don't have any metrics for performance. They aren't asking about performance they are asking about how secure it is.
Alberto Biasiutti 30-Nov-11 2:44am
   
Well, I'm stuck between security and performance.. the doubt is: is effectively faster to have the information in session than picking data at each request from the db? If yes, how dangerous is it? I'm already performing base asp.net Form authentication and my users already have roles.. I'll extend the question so that the whole situation is more clear.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900