My asp.net application is deployed on a load balance system. And I just want to keep a user's role (a string) in a whole session. I was told that session info in asp.net is stored in the database so I don't want to the asp.net engine to access DB ecah time a user switch between pages. neither do I want to get the role from my own DB each time when I need check user's role. I know one way is to store the role info in a hiden field.
what is the efficient way to store a constant session value?
session has three modes. The mode setting supports three options: inproc, sqlserver, and stateserver. you need load balance, the inproc is out automatically. you can configure to use either sqlserver or stateserver.
If you want to avoid DB accesses, you might use cookies to store the user's role instead of session state. You can encrypt / encode the cookie if you need to for security reasons (perhaps using the session ID as part of the key). Cookies work fine in a load-balanced scenario, since they are sent by the browser to the server with every request. Just be sure to set the path attribute on the cookie (and possibly HttpOnly), to limit the URLs that the browser attaches it to.
Note that if you're using the built-in ASP.NET Membership providers, role membership and related details are handled for you automatically by the providers.
You could also use a cookie.
Session data is stored by default in memory, so i guess you have it configured to be stored in a database in order to be available on all servers in the farm.
If you can store it in memory, you could use this approach to deal with the load balancing:
if (Session["Role"] == null)
Session["Role"] = GetUserRole();
This will result in trips to the database only once per server.
More details about Session state here.
If "role" has something to do with permissions it would not be a good idea to store it in a hidden field or an other means that would enable it to be edited from the client side such as in viewstate with talking asp.net.
I am a big hater on session, especially if you are using it to hopefully improve performance. What you probably really want is caching and there a number of great solutions you can look into. Right away you can take advantage of the Cache data dictionary that is built into asp.net and is exposed as a member on the page class. The cache will essentially serialize anything you put in it and store it in memory. Using the cache object will work best with a single server setup. Since you are using load balanacing you will probably want to take advantage of a distribute cache system like Memcached or AppFabric Caching (Previously Codename Velocity). Memcahed is used by a lot of big sites such a Twitter where as AppFabric is a new Microsoft product that is just becoming available but should have good support and integration with other Microsoft technologies such as Asp.Net.
With distributed caching you avoid going back to the database and you essentially trade this off for a trip to your cache. The reason why this is more efficient for starters is that the cache only has to worry about efficiently storing items which have been recently accessed where as the database must store everything.
Also I want to point out that you may choose to avoid the distribute caching route if you are using server affinity with your load balancer. Technically you could use it without server affinity as well but you will have a lot more cache misses.
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 am creating a website,for that I need some kind of storage medium so which one can I use and which one will give better performance to the website.
session
cache
cookie
please give your suggestions.
It all depends on the scenario and their usage.
Basically Caching is used to boost performance and Session is used to share data between multiple pages. Excess use of session bogs down the performance. Cookies are stored on client side and can be used to keep less confidential data on Client browser.
So you have to use all of them wisely to deliver performance
Session is used to store per-user information for the current Web session on the server.
Cookie is used to store per-user information for the current Web session or persistent information on the client, so client has control over the contents of a cookie.
Cache is shared between users in a single application. Its primary purpose is to cache data from a data store and should not be used as a primary storage. It supports automatic invalidation features.
If your application is used by a number of unauthenticated users, then it would be better to store the data in a cookie.If it requires authentication, you can store the data in the DB manually.
On whole this it depends on your need.
session is a way to store variables stored in a session object so that it is accessible to all web pages hosted on the server for a user.
Cookies stored on client machine so not much safe to go for it unless variable are not so restricted.
Cache helps your browser go faster.Hence Caching is used to build high performance web applications.
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).
I'm working with an asp.net application that stores most data in a database and not session. I'm wondering of the pros and cons of each and which is the better way to go. For example, you have a pretty busy site and instead of storing user specific variables in session, there is a DB table called user data and it can store all user specific data that can be accessed from any page by querying the database. Which is the better way to go, session or database?
Session (but it depends a lot of the session configuration) :
No database access, or less.
Temporary storage : you may lose the information, at least when the session ends.
Maybe some security issue, depending on where you store the session information
Not shared : you may have issues if you're using a server farm, one server may not have access to the other server session.
May not work if the client disabled the cookies.
Database :
Database traffic for each postback if you need the information on each page.
Permanent storage.
No information stored with the client (cookies...).
Shared : data accessible from any server on a web farm.
Please note that you can store Session information in database. That's why I use the word "may" in the Session part.
See here some session configuration and possibilities
Anything stored in session state will vanish when the AppDomain is reset.
You could avoid that by using an out-of-proc session state handler, but that's no better than a database.
Interesting question. If it's data that's not important across sessions (say, last page viewed) -> session. If it's data that should be persistent (say, password) -> database. The interesting case and the one you probably refer to: Data that should be persistent but is also used often (say, the username). From these, I tend to copy those values from the DB into the session that allow me to work without database access in pages with trivial tasks.
In many cases, I use Session to store temporary data about the... well... "session". In ASP.NET, session is configurable. You can use in-proc (default) which uses the server's memory. You can also configure session to use a database or a session management tool (in case server memory is a problem or you move to a cluster/farm environment).
Session is meant to be temporary. This is great when you are truly storing data about the user who is using your application at that moment. When the user leaves the app and his/her session expires, the memory is freed up. You don't have to manually clear anything out.
Session uses the server's memory. As long as you have enough memory and you're not on a server cluster, this works great. Memory is fast, so getting and setting data in session is very fast and uses zero network bandwidth.
Have said all that, in a few of my apps, I have session configured to use SQL. It's basically the same as using the database directly, but I don't have to deal with DAL... just let the framework work for you.
I'm porting an ASP.NET application to MVC and need to store two items relating to an authenitcated user: a list of roles and a list of visible item IDs, to determine what the user can or cannot see.
We've used WSE with a web service in the past and this made things unbelievably complex and impossible to debug properly. Now we're ditching the web service I was looking foward to drastically simplifying the solution simply to store these things in the session. A colleague suggested using the roles and membership providers but on looking into this I've found a number of problems:
a) It suffers from similar but different problems to WSE in that it has to be used in a very constrained way maing it tricky even to write tests;
b) The only caching option for the RolesProvider is based on cookies which we've rejected on security grounds;
c) It introduces no end of complications and extra unwanted baggage;
All we want to do, in a nutshell, is store two string variables in a user's session or something equivalent in a secure way and refer to them when we need to. What seems to be a ten minute job has so far taken several days of investigation and to compound the problem we have now discovered that session IDs can apparently be faked, see
http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/
I'm left thinking there is no easy way to do this very simple job, but I find that impossible to believe.
Could anyone:
a) provide simple information on how to make ASP.NET MVC sessions secure as I always believed they were?
b) suggest another simple way to store these two string variables for a logged in user's roles etc. without having to replace one complex nightmare with another as described above?
Thank you.
Storing the user's role information in a server-side session is safe providing a session cannot be hijacked. Restating this more broadly, it does not matter where user role info is stored if an authenticated session is hijacked.
I advise not putting too much faith in the article you linked to, but the 2002 vintage report linked to from your link is of interest. Here are my take-aways:
Don't accept session IDs embedded in URLs.
Focus your time on eliminating cross site scripting dangers i.e. scan all user supplied data and parse out executable java script.
Issue cookies for complete domains (e.g. myapp.mydomain.com)
Host your domain at a high class DNS operator e.g. one that only allows DNS changes from a preset remote IP address.
Don't issue persistent session cookies.
Reissue a session cookie if someone arrives at a login page with a sessionID already associated with an authenticated session.
Better still, always issue a new session cookie on successful authentication and abandon the prior session. (Can this be configured in IIS?)
The only way to make a secure cinnection is to use SSL. Anything less than that, and you simply have to make the evaluation when it's "safe enough".
A session variable works fine for storing a value, with the exception that the web server may be recycled now and then, which will cause the session to be lost. When that happens you would have to re-authenticate the user and set the session variable again.
The session variable itself is completely safe in the sense that it never leaves the server unless you specifically copy it to a response.
Have you considered setting up a custom Authorize tag in MVC. I gave an example of this in another question.
On initial authorization (sign-in screen or session start) you could seed a session value with the IP address also. Then in your custom authorization, you could also verify that IP's still match up as well. This will help make sure that someone isn't 'stealing' the person's session. Everytime you access your session data just make sure to pass the requester's IP and have some check on it.
Are you trying to control the access to functions at the client level? That is the only reason I would expose the roles and items to control client side functions.
Alternatively, you could create a function to obtain the items that the roles of the user are allowed to use, and then even if the function is called outside of the items given back to the web application, you can prevent the user from accessing them.
4Guys seems to show how to control functions with the roles.
The approach I have used in the past is to use symmetric encryption of a cookie alongside SSL. Encrypt the user information in the reponse and decrypt it in the request. I'm not claiming this is foolproof or 100% secure and I wouldn't want to do this on a banking application, but it is good enough for many purposes.
The main issue with session variables is that if you store them inProc rather than persisting them, then you need to apply 'sticky' sessions to your load balancing in a web farm environment. Guffa is correct that without this persistence session variables will occasionally be lost causing a poor user experience.
Sticky sessions can lead to uneven load balancing, perhaps reducing the value of being able to scale out.
If you are going to be be persisting the sessions so they can be accessed by all servers in your web farm, you may be better off using a Guid to identify the user, encrypting this in a cookie and retrieving the user record from your data store each time.
My obvious question is that why do you want to store a users role in session ?
Here is my answer to your query, how this helps. I have attached a small demo application for you to take a look at and understand my points. When you open this project in visual studio, click on the project tab on the top and select asp.net configuration. From the page that will show up you can do the user administration stuff.
You need to store the roles of a user in some secure manner ? The answer to this question is that there is no need for you to worry about storing the role for any user, when we have the asp.net membership, profiles and roles framework to help us out on this. All you need to do is create a role in the aspnet database and assign that role to the user.
Next you want to store two string in some secure manner. I suggest you user profile for storing user specific information. This way you have the information available to you where ever you want from the profilecommon class.
Also please see the attached demo application placed at the end of my blog http://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx
Just a suggestion, you might consider using this little library:
http://www.codeproject.com/KB/aspnet/Univar.aspx
It has a server side implementation of the cookie whereby all cookies can be stored on the server while asp.net authentification is used to identify the user. It supports encryption and is also very flexible making it very easy to switch from one storage type to another.