Using session to store "security" related info

Question

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 29-Nov-11 7:36am

Alberto Biasiutti

Updated 29-Nov-11 21:12pm

v2

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Not Active · Accepted Answer · 2011-11-29T08:21:00

Solution 2

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[^]

Posted 29-Nov-11 8:21am

Not Active

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.

GateKeeper22 · Accepted Answer · 2011-11-29T08:18:00

Solution 1

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

Posted 29-Nov-11 8:18am

GateKeeper22

Updated 30-Nov-11 4:33am

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.