使用会话状态在asp.net中创建用户登录名和角色的不安全方法

Question

Consider the setup where a list of ids and passwords are stored in a database on a server and when a user enters his login credentials then the code-behind verifies it against the server and sets values like Session["id"] Session["login"] to determine whether user has access to certain page.

When a user attempts to browse to a page, the page looks at session variables and then relocates the user if need be and adjusts the buttons on its page accordingly.

How secure is this setup.

The built in login and role functionality of asp.net seems too rigid so I was trying to explore other options.

Answer 1

The Session State is a safe way to keep track of user log-ins. Assuming the default set-up (in process, cookie-based session), it will be just as secure as Forms Authentication. The exact level of security you get with it will depend on how you configure your Session State.

1. Cookieless session state -- this opens up some potential security loopholes (eg user shares the url that contains the session ID, user takes a screenshot that contains the URL with the session id, etc.)

2. Out of process session state -- If you are using a remote session state service (or a database for storing the session), your Session's security will depend on you locking down access to the session state service or DB appropriately.

That said, the built-in login and role functionality that you get with Forms Auth is not too difficult to extend and build upon, rather than rolling something from scratch. If you need something custom, you can also write your own membership and role providers . This is helpful if you need to lock down routes based upon user name or role, as you can do it right in the web.config.

Answer 2

The major flaw in using Session is that it could open up your site to a Session Fixation vulnerability. As the session is established when the user arrives on your site, it may be possible for the session ID to be discovered (eg by a MITM ).

Example steps are as follows for this exploit:

1. User arrives on HTTP site, ASP.NET gives them a session and sends the session cookie to user.
2. Attacker reads the session cookie value.
3. User goes to login form (HTTPS), logs in and your id and login values are stored in the session.
4. The attacker sets their session cookie to be the intercepted value from step 2.
5. The attacker now has a valid, logged in session, hijacking the now logged in user.

For this reason alone, I would recommend using the built in login and role functionality as the auth cookie is not set until the authenticated session is established. If you insist on the session method, I would recommend you call Session.Abandon() to grant the user a new session upon login, so that their session is not the same as their previous, unauthenticated session.

Please also see my answer to this question: https://stackoverflow.com/a/18077422/413180