User roles - why not store in session?

Question

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.

Answer 1

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:

1. Don't accept session IDs embedded in URLs.

2. Focus your time on eliminating cross site scripting dangers i.e. scan all user supplied data and parse out executable java script.

3. Issue cookies for complete domains (e.g. myapp.mydomain.com)

4. Host your domain at a high class DNS operator e.g. one that only allows DNS changes from a preset remote IP address.

5. Don't issue persistent session cookies.

6. Reissue a session cookie if someone arrives at a login page with a sessionID already associated with an authenticated session.

7. Better still, always issue a new session cookie on successful authentication and abandon the prior session. (Can this be configured in IIS?)