What is the disadvantages of storing user role including admin in a session variable?

Question

In my projects I always fetch roles from DB and store them in a session variable, then to check If a user has access to admin pages I just check the session.
Let's consider I use a private hosting what is the drawbacks of this approach?

Answer 1

Let's say a non-admin user edits their session cookie and changes admin=false to admin=true. Is that a problem, that any user can trivially bypass all your access controls?

You should give each user a session token like 3f235219b2cca1842b4ae2dd9ec4a1a8570f2edf that is stored in your database with a lifetime. You check that the token exists by constant time comparing the whole string and if the user with a token exists and is not expired, then you check if the user has privilege or not.

You also probably want to have it be an HTTP only (not editable by javascript) and Secure cookie (only set via https to prevent MITM).

---

EDIT: http is a stateless protocol. Meaning that each http request coming to your server starts over from scratch; the web server isn't aware if you've accessed this page for the first time or are continuing a multi-page visit to the site. The basic way to create a session is to have some identifying variable get passed back to the webserver with each request; say through a hidden GET/POST variable, a changed URL, or more typically a cookie. A cookie could be set in an HTTP response from a webserver like:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: user_role=guest
...

and then when you make your next request to the webserver:

GET /index.html HTTP/1.1
Host: www.example.org
Cookie: user_role=guest
...

Note that since the user has full control of their web browser, you can't really trust the variables they are sending back. E.g., they could change user_role=admin. So the solution is to store the information about the user on the server-side. So a user authenticates with the server, then you give them a token (some long random string fSFrKtJXAnjo9wacE3XNMy) and store on the server-side that token=fSFrKtJXAnjo9wacE3XNMy is tied to someone with user=guest (and anything else you need to know about their session state). You want http-only cookies, so its harder for XSS-style attacks to steal your session cookies, and secure so eavesdroppers can't trivially listen in.

Answer 2

A non authorized user should be stopped way before a call is made to populate the session details. You would be authenticating and authorizing the user in AuthenticateRequest & AuthorizeRequest events which are triggered before AcquireRequestState event. So, if the user is not authorized to view a resource, the rest of the events will not happen and hence we can avoid the load on DB or other resources.

The life cycle is depicted at Remarks Section of HttpApplication Class in MSDN