6

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?

Be.St.
  • 4,101
  • 3
  • 25
  • 35
w.donahue
  • 10,790
  • 13
  • 56
  • 78

4 Answers4

5

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

Be.St.
  • 4,101
  • 3
  • 25
  • 35
  • 2
    I agree that the first question should be - do I really need to do it this way? Beyond storing auth information, you should really aim for being as stateless as possible. – Bryan Naegele Jan 17 '12 at 08:37
  • Good answer. An alternative is the AppFabric velocity cache for storing state - see my answer below. – Nick Ryan Jan 17 '12 at 09:13
4

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).

smartcaveman
  • 41,281
  • 29
  • 127
  • 212
2

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.

Community
  • 1
  • 1
Tom Chantler
  • 14,753
  • 4
  • 48
  • 53
1

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).

Nick Ryan
  • 2,662
  • 1
  • 17
  • 24