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:
A remote attack, like a modified POST or other handler call to a
page?
Would an attacker with programmatic access to IIS (WMI mabey?)
be able to access and change session-state in the same or another app pool's memory?
Would an attacker need to be able to post code to my app, in order to manipulate session memory?
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.
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.
Session cookies are not, by default, encrypted and are passed as plain text.
Session Fixation attacks are easy to accomplish
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.
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...
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
Related
Using ASP.NET I have always used session variables to maintain a users session data.
Typically: (Coded as simple bools/ints with around 12 total variables)
User information.
Page security permissions.
I have read increasing information regarding the negative effects of using session variables.
I am aware that session variables are stored in memory and the negative effects that using too many can have; this is not the desired scope of this question.
What I would like to know:
Using current development languages and features:
Do session variables pose a security risk?
(By security risk I mean is it possible to read / alter variables)
Is there better performance using querystrings, viewstate, caching, or making database request on every page load?
What is "considered" good practice for handling a users session data. (All topics relating to this subject are now very old and perhaps no longer relevant)?
A performance is always something subjective and may vary depending on different things. In your case you're trying to compare incomparable because
querystrings cannot be used to share sensitive user information or page security, because everyone can modify urls directly in the browser
viewstate is set and maintained on the page level. It cannot be carried across different page requests, only on postbacks of the current page.
caching is done on the application level, and all users can access it. It might work in case of page security permissions but not applicable to store individual user information.
Making database requests is the only comparable option and yes, it's slower than a session. This is where you can try to play with viewstate and caching and try improve performance and reduce a database workload.
Sessions are stored in a memory on the server but depend on cookies and in theory, it's possible to hijack the session by stealing the asp.net session cookie.
SessionID values are sent in clear text. 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.
Quote: http://msdn.microsoft.com/en-us/library/ms178581.aspx
Bottom line: using sessions is secure but to make it more secure use HTTPS
ASP.NET provides out of the box functionality for user authentication, role based authorization and user profiles which might make sense to use. Read more about profiles: How to use Profile in ASP.NET? and Regarding Profile and session in asp.net There is a lot of other topics and answers here on this site regarding authentication and authorization.
Do session variables pose a security risk? (By security risk I mean is it possible to read / alter variables)
Although, as smirnov quoted, a malicious user might get accrss to another user's session by hijacking the session itself, the session variables themselves are stored at server-side, and cannot be accessed directly.
Is there better performance using querystrings, viewstate, caching, or
making database request on every page load?
As smirnov wrote, the comparison isn't exactly valid. However, consider:
querystrings and viewstate are stored in the http request, therefore are both less secure and consume no memory. However, they will take some minor processing power to parse.
Caching (in the web-server RAM) the results of previous database request will lighten the load on the database and the network connections between your web-server and the DB server, and will also retrieve the data faster. However, they will obviously use more RAM on the web-server itself.
What is "considered" good practice for handling a users session data.
(All topics relating to this subject are now very old and perhaps no
longer relevant)?
Since the principles haven't changed much, the existing sources, IMHO should still be relevant.
Note: If you're using multiple servers, you'll need to synchronize the session data across them, by using a state-server, for example, or use "sticky sessions", in which each session is always served by the same server.
In my opinion you should avoid sessions as much as possible. Here are my reasons in no particular order.
Sessions doesn't scale automatically when you add more nodes (Sure you can use a dedicated session-server but that comes with some overhead)
When you have enabled sessions each user can only make a single request at the same time. Asp.net implements per user locking if the session is enabled to avoid any race conditions. This is mostly a problem in if you use a lot of ajax.
If you have to restart the webserver the user lose their session. This is really the main point for me. It really sucks to have a system where people risk to get kicked out, get a corrupted session or simply lose progress because you need to deploy a bugfix. Avoiding session as much as possible gives you much more freedom and a better experience for your user.
It's up to you but I always try to either store the data in a persistent store or use something that actually exist in the web (cookies, querystring, writing state to a hidden field etc etc). I bet there are situations where I would use sessions but my default choice is to avoid them.
These days there are more options:
Local Storage / Session Storage / Page Javascript Variable - are good for client-side storage situations. see https://www.w3schools.com/html/html5_webstorage.asp. But they wouldn't be suitable for most trust situations, not without server-side signing. A javascript variable will be lost upon page restart, but persist in browser Session Storage if it was written there. If that browser tab is closed, the Session Storage is lost, but persist in the Local Storage if it was written there.
JSON Web Tokens (JWT) - are the emerging new standard for replacing Sessions. This is a standard for authentication, roles, data, and claims, which is signed by the server, and can also be encrypted to the client can't read any of the details. This is usually stored in Local Storage by the client, and only really works for Single Page Applications which can write to the Bearer header. Don't use this for MVC (MVC.Controller) with server-side generation of HTML. JWTs can be a pain to set up and customise - the API for OWIN is terribly sparse. JWTs can get big too, which means you're always "uploading" the JWT data upon each Request to the web-server. But JWTs enable your security to be handled by one server (even an externally trusted server).
ASP.Net Server-Side Sessions - Can be in-memory in-proc, in-memory external-proc, and database.
Answering your specific questions:
Security risk - Not really. The session uses a key that's long enough that it can't be guessed. It's typical to use HTTPS these days, so that value is securely transmitted. The variables are stored only on the server, with a set per user. If a user's device is compromised, it's possible to steal the session key, but if their device is compromised, there are bigger problems to deal with.
Performance is not better or worse for "query strings", "view state", or "caching" compared to In-Proc (Memory) sessions. They're all in the realms of speed of memory (RAM) - nanoseconds. Database (disk stored) is certainly slower, because the medium access time is slower - milliseconds
Sessions are good practice. Some would recommend having a dedicated class for reading and storing each variable (using Properties), so you don't get the session variable names (strings) confused.
I am a fan of a possible hybrid approach to Sessions. see How can I store Session information in a hybrid (Database + Memory) way?
I want to implement measures to prevent/mitigate session hijacking. Thus, I want to know the options, either from built-in ASP.NET or custom components.
Please note that session hijacking refers to Forms Auth session and Session State.
My ASP.NET is using HTTPS for all pages all the time. But it is possible that session can be compromised once the session cookie id is obtained by third party somehow, e.g. from user's hard drive, cross-site scripting attacks, and man-in-the-middle attacks
In particular, I am concerned about session id hijacking because https is used all the time for my projects
Below is the links I reviewed, which are written a few years back:
Foiling Session Hijacking Attempts Jeff Prosise Please refer to Caveats section for its shortcomings.
I cannot find much relevant information, or different from Jeff's on the web.
Here are a couple suggestions:
Salt your sessionId. This would ensure that you have unique session Ids - although, I am pretty sure the default ASP.NET session Ids are unique enough for your purposes; however, for added security you could use something that either you can control or is self-identifying. For instance, you could use a GUID as a salt - which you can control by updating as you see fit.
Track the SessionId and user ip address of your users as a pair in a dictionary object. This would enable you to match the session Ids to the ip address and reveal any session hijacking that is occurring outside of the user's LAN. Obviously not without flaws as it won't matter much if the user's computer or router is infected, but it will at least make it more difficult for the attacker to accomplish their task.
Not sure what you would do if the user's computer is infected, but that risk exists whether you increase your defensive measures or not.
I'm using a login form to authenticate users.
FormsAuthentication is right out as it stores sensitive user/role membership in either client-side in a cookie or within the URL. Within the URL is a huge security risk, so I won't even get into that. With the
FormsAuthentication cookie, this creates problems with a) security where the client is in the position of dictating it's own roles; and b) way too much data stored in cookies. Since I'm gaining nothing through security and loosing out big time on the size of user data storage, I'd rather just work with Sessions.
I'd like to reuse something like FormsAuthentication for all its basic login form-handling features. But i would rather have it store user data server-side in perhaps Session rather than client-side all stuffed into a single cookie. I'd rather just authenticate against a Session token of some sort.
I have no database and local disk storage of user data is forbidden. I rely on a 3rd party authentication service provider, and a requirement is that I must reduce chatter with this service. Thus, sessions for temporary storage of user info. Sucks, but that's not necessarily the problem I'm asking about. Also, a requirement is that I must set/use HttpContext.user and likely Thread.CurrentPrincipal for use later on in such things as AuthorizeAttribute, for displaying user info in views, etc.
So FormsAuthentication stores all user data client-side in a cookie. Whereas Session stores all data server-side and just relies on a simple client-side token cookie. However, Session is not available anywhere during the asp.net startup and authentication steps. Is there an equivalent forms "membership" provider that stores all data in Session server-side instead of client-side?
If there is no Session equivalent...
Where do I set HttpContext.user and Thread.CurrentPrincipal to make both values available throughout the rest of both MVC apps without interfering or messing up other MVC components?
Hinging on #1, is Session available at that entry point? If not, how do I make it available so I can create the Principle/Identity object using the data stored in Session?
This can't possibly be a unique requirement. Are there libraries already available which handle this?
Session stores information in a client-side cookie too! (or in the URL if cookieless).
If you want to authenticate a client, he'll have to provide some kind of credentials - usually an encrypted token in a cookie once he has logged on. If not a cookie, then what do you propose?
You should use FormsAuthentication. The sensitive information stored in a client-side cookie is encrypted using a key that should only be known to the web server. "the encryption methods being public knowledge" doesn't mean that you can decrypt the data without access to the appropriate cryptographic key.
You mention "roles" and a "third-party authentication provider". If your third party is also providing roles (i.e. an "authorization provider" as well as an "authentication provider"), then it would be reasonable to cache roles obtained from the provider on the server. Session is not available when a request is being authorized, so the best solution is to use the Cache (System.Web.Caching.Cache).
Personally I would encapsulate this in a custom RoleProvider. The custom RoleProvider would implement GetRolesForUser by getting roles from the third party on the first call, then caching them in Cache.
Not sure if I like what I'm about to suggest, but you could do the following:
Leverage the Application State or System.Cache as a global storage for user credentials.
Use an InMemory database (like RavenDb) which can also have encryption (in memory, I believe).
Using the Application state as a place to storage relatively common / frequent stuff I think is not a great place because of
Scaling / locking issues? <-- just a gut feeling.
Permenant data? so you have users in the website's memory .. then the website crashes or recycles, etc... what happens now to that data?
RavenDb is awesomeballs - go.use.it.now.
I understand that you are not storing anything locally, so whenever a user hits your system, you need to refresh your inmemory cache, etc. Fine. A pain in the f'ing butt , but fine none-the-less. (EDIT: unless the data has been cached in memory .. that is)
Anywys, two suggestions.
ProTip:
Oh! move away from role based shiz and start using Claims based identity stuff. Yes, it still works with IPrincipal and HttpContext.User, etc. So all previous code is NOT busted. But now it's baked into .NET 4.5
Awesome Video on this for you, me, everyone!
Finally - bonus suggestion
A nice package that auth's with either Facebook/Google/Twitter. You said you're keeping the user cred's on another site (good move!). If you're using other providers, then stick with DNOA or SS.
GL!
I need to store some session related data for a user. This data does not need to be encrypted but I want to ensure the user cannot modify it. I think my options are to store it into a hidden field, store it into a cookie, or store it in ASP.Net session state. I need the solution to be server farm safe.
If its stored in a cookie or hidden field then I need a way to ensure a user can't modify it.
What do you think is the best approach for this sort of data?
First question I ask myself about session data: I really need them?
Remember that web is stateless so maybe you can re-engineering your application to not use session state.
Sessions requires a lot of management and server resources.
Meanwhile you have two solutions:
because you are in a farm put your session on SQL Server configuring session state in web.config (it requires resources and it's a bit slower but is the safest way to store session data to ensure the user cannot modify it)
add an encryption/decryption mechanism to your cookie with a private server key
A user is always able to modify cookies, because it is client-side storage. You need to store the data server-side.
ASP.NET Session State is an acceptable solution for your problem, although there are some caveats regarding server farms. This MSDN article explains how to make Session State work for your server farm environment. Be.St.'s answer touches on the suggested out-of-process approach.
A third alternative is to create a database driven session storage that does not necessarily depend on Session state. I find Session State to be a bit of a hassle with different deployment environments (e.g. server farms), so I will sometimes use this approach. You can then access this data by attaching a session key to the querystring or storing the session key in the cookie (still potentially modifiable by the user, but less likely to be a target for such action).
Personally, I reckon it's better to store the information in the cache, although you could perfectly well store it in the session or encrypt it and store it in a cookie and it's just a matter of personal preference
The reason I prefer the cache is that it is not vulnerable to Session Hijacking, so there is no possible way the user can modify it as it's stored on the server (same as session in that respect).
I asked a question about using a custom principal and I included quite a bit of code in there that might help you.
Code to store extra user information in cache: Is this Custom Principal in Base Controller ASP.NET MVC 3 terribly inefficient?
EDIT: And the reason I prefer to store this information somewhere close at hand is that I don't want to kep nipping off to the database all the time as it is very inefficient to do so.
If you need to use a farm and want to share session state among the nodes without going back to the database all the time you could use the AppFabric Session Provider. There is a bit of a learning curve setting it up but it does the job and is fast (don't run it on the same box as your application though).
What's the best way to authenticate and track user authentication state from page to page? Some say session state, some say cookies?
Could I just use a session variable that has the ID of the user and upon authentication, instatiate a custom User class that has the User's information. Then, on every page, verify the session variable is still active and access basic user data from the User object?
Any thoughts? Any good examples?
The problem with favoring sessions over cookies for 'security' is that sessions USE cookies to identify the user, so any issue with cookies is present with sessions.
One thing to keep in mind with the use of Sessions is data locality. If you plan to scale to more than one webserver at any point, you need to be very careful storing large amounts of data in the session objects.
Since you are using .NET, you will basically have to write your own session store provider to handle this, as InProc won't scale past 1 server, the DB provider is just a bad idea entirely (The whole point is to AVOID DB reads here while scaling, not add more), and the StateServer has a lot of capacity issues. (In the past, I have used a memcached session store provider with some success to combat this issue).
I would google for signed cookies and look into using that instead of either regular cookies or sessions. It solves a lot of the security concerns, and removes the locality issues with sessions. Keep in mind they come back and forth on every request, so store data sparingly.
There's no perfect way to do it. If you store it in a cookie you'll take flak that cookies can be stolen. If you store it in the session you'll take flak because sessions can be hijacked.
Personally, I tend to think a session is a little more reliable because the only thing stored on the client is a session key. The actual data remains on the server. It plays the cards a little closer to the chest, if you will. However, that's just my preference, and a good hacker would be able to get past shoddy security regardless.
No matter what you do, don't try to implement this yourself. You'll get it wrong. Use the authentication system provided by your specific platform. You also need to make sure you have adequate security precautions protecting the authentication token.
I dont know if its THE BEST way to do it, but we are comfortable with the way we do it.
we have a custom user object that we instantiate when the user authenticates, we then use Session to maintain this object across the application.
In some application we combine it with the use of cookies to extend the session continuously.
Cookies and Sessions by themselves are not truly sufficient. They are tools to use to track the user and what they do, but you really need to think about using a database to persist information about the user that can also be used to secure the application.
Sessions are Cookies...