0

This is a follow up to a question I posted earlier, but was unclear then. I hope I can be more clear now.

I'm using ASP.NET and C# to validate a user after login on all secure pages. I should be able to do this without touching the web.config files so please avoid any such solutions that involve editing the web.config file. After some debugging, I've found that wehn a user logs in, the secure pages can be accessed by any other person (without logging in) from another computer, or simply on the same computer but in a different browser. This is obviously bad, so i'm wondering how I can use the initial session ID of a valid user to protect all subsequent page_load's from other users who have the direct page path, but not a valid login.

At the moment, the only check I do in all secure page_load functions is to check wether MySession.GetSessionId()==null. How can I use this value returned by GetSessionId() to check against what the initial session ID value was upon logging in?

Nibirue
  • 411
  • 1
  • 15
  • 29
  • 3
    Use ASP.Net Membership and roles. http://msdn.microsoft.com/en-us/library/yh26yfzy%28v=vs.100%29.aspx. It does this for you. How are they logging in? How are you storing passwords? How are you handling roles? If you are trying to build your own authentication system to avoid editing the web.config, you will likely run into more problems than this. – MikeSmithDev Jan 14 '13 at 23:59

3 Answers3

4

Session is already unique per user and per user agent. If multiple users are all accessing the same session, there is definitely a bug in your session creation and setting logic, likely where the user ID is being set. My psychic debugging tells me either that:

  • all users and credentials are set to the same values from a persistence store of some sort by accident, or
  • you are storing a reference to the session in a static field somewhere, the value of which is shared by all users

However, without showing the code it would be difficult to debug.

John Rasch
  • 62,489
  • 19
  • 106
  • 139
  • I appreciate the useful advice, but this doesn't answer the question I asked, or at least my intention of asking. The session ID from each instance is different, but they are still aloud to log in. I believe I have the solution, which I'll post here soon if debugging works out. – Nibirue Jan 15 '13 at 20:21
2

Just relying on the sessionID is not the way to go! You don't have any information of the user just by checking the sessionID.

Store the userID of the logged in user in the session. Then check on the secure pages if there is a valid userID.

Not the most elegant solution, but this way no need to change to web.config.

I suspect however that the authentication/authorisation logic in the website doesn't make full use of the membership functionality shipped with asp.net.

Perhaps you can score some points by pointing that out an deliver a long standing and secure solution.

lboshuizen
  • 2,746
  • 17
  • 20
  • +1 for pointing that out. Manually checking for session objects really would fail in a long run. – Zo Has Jan 15 '13 at 07:22
0

Quick & dirty solution. Check pseudo code

On login page (Login.aspx)

BtnLogin_click()
{
        // Query database to check username/password match
        // If Success store corresponding UserID in session
        Session["userID"]=YourDbValue;   // Say 1 is for administrator, 2 is for user
}

On secure pages (Secure.aspx)

 PageLoad(){
       if (Session["userID"]!="1")
          // Log this attempt somewhere  
          Response.Redirect("~/NotAuthorized.aspx"); 
   }

I strongly suggest you to go against this approach & implement a proper membership system because you have to hard code this in each & every page, if not you are still in trouble if in future many administrator roles are added to the site.

Damien.

Zo Has
  • 12,599
  • 22
  • 87
  • 149
  • I agree, but I am doing what i was asked to do verbatim (i'm in training at my job). Thanks for the help. – Nibirue Jan 15 '13 at 20:23
  • You could also store the roleID of administrator if you have a role table in your database. – Zo Has Jan 16 '13 at 05:24