Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
What do you mean by "session variable"? Do you use standard implementation of sessions that is available in your framework? Do you use server side session storage? If so, that's OK. But if you use client side session storage without integrity protection, than you are in trouble. –  pgolen May 3 '12 at 13:30

2 Answers 2

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.

share|improve this answer
I've already implemented token in my DB and checks against it. –  Sheriff May 3 '12 at 12:29
You mean we can change session with JS?? –  Sheriff May 3 '12 at 12:32
@Sheriff - Edited. –  dr jimbob May 3 '12 at 14:26
The question is pretty vague, but by session variable I understand server side state, which is matched to a user based on an opaque token cookie. –  CodesInChaos May 3 '12 at 14:30
@CodeInChaos - Agree it was vague and session variable could go either way. I tried saying the unsafe interpretation was unsafe and that instead you need to do the another method (which happened to be the safe interpretation of session variable). –  dr jimbob May 3 '12 at 20:27

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

share|improve this answer
Can some one educate me why this was down voted? –  Ramesh May 30 '12 at 5:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.