views:

37

answers:

3

Hello! I am developing the application that stores current user and user's role to session state (System.Web.SessionState.HttpSessionState Page.Session).

        if (Session["username"] == null)
            Session.Add("username", User.Identity.Name);

        if (Session["isAdministrator"] == null)
            Session.Add("isAdministrator", User.IsInRole(domain + "\\Domain Admins"));

After I check these session states in code behind for granting permissions to some excecution:

    if ((bool)Session["isAdministrator"] || computer.Administrators.Contains(Session["username"].ToString()))

My question is next: how safe that mechanism is? Is it possible to change the session states using some JavaScript for example or some how else?

Thanks :)

A: 

In general I would say this is very safe from XSS attacks. ASP.Net, by default, tracks a users session based on a Cookie which contains the users session ID. You can see this if you open your browsers cookie list and look for ones from your site, there will be one there named ASP.Net Session something... The SessionID's unique, and not incremental. Probably some variance of a GUID.

For added security you can also specify, in your web.config, how long to keep a users session alive. If you are dealing with sensitive information you might want to set this timeout to be relatively short period of time, maybe 10 minutes of inactivity, the default is 20 minutes. You can find more info @ http://msdn.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.timeout.aspx.

<system.web>
    <sessionState timeout="10" />
</system.web>

--Peter

Patricker
+2  A: 

If User.Identity.Name is set, why do you need to put it in the Session? Why don't you just call User.IsInRole(domain + "\\Domain Admins") directly (or wrap it in a helper)? It looks to me like you're using Windows Authentication, so setting the username in the session is redundant.

As for your XSS question, the session stores the session ID in a cookie, so in theory an attacker could be sniffing the HTTP traffic or inject JavaScript code into your pages, get a hold of the cookie, then use it and impersonate another user.

John Rasch
Yes, thank you. I think it is better to compare User.Identity.Name directly and not the session state value.
Juri Bogdanov
+1  A: 

It is not possible to change the session state using javascript or other client-side mechanisms, as the state is only stored on the server. However, it is, as others have pointed out, possible for a malicious user to hijack a session by getting hold of the contents of the session cookie.

ASP.NET is designed with this weakness in mind - the session ID is suitably long and hard to predict. Also, the session cookie is marked as HTTP ONLY, which means that most modern browsers will not allow javascript code to access it.

Jonas H