I have a question connected with security.
Is it possible to implement authentication and authorization trough session variables without using forms authentication and forms authentication cookie stored in browser?
How is session id being sent in consecutive requests? Is it stored also in a cookie?
What are the drawbacks of using session instead of forms authentication for authentication?
Thank you
Using user session for authentication is a very bad idea from the security perspective. User session is maintained by a cookie (ASP.NET_SessionId), just like the authentication session (ASPXAUTH). However, ASP.NET has a lot of security safeguards built into the authentication session cookie management, such as encryption, validation, prevention of tampering, etc. None of these measures exist for the user session cookie, which makes it easy to break the site security.
There is absolutely no reason not to use forms authentication, it is actually more difficult to switch to using the session for authentication, because you have to custom code to support it.
Well, you got two questions.
Is it possible to implement authentication and authorization trough session variables without using forms authentication and forms authentication cookie stored in browser?
yes it's possible but we're not supposed to reinvent the wheel especially it is related to security. It's strongly recommended to use form authentication when possible unless you have strongly valid reasons.
How is session id being sent in consecutive requests? Is it stored also in a cookie? What are the drawbacks of using session instead of forms authentication for authentication?
to see the cookie.
step1: Create a new ASP.NET MVC project using internet template.
step2: Start it and create a new user and login.
step3: Open developer tools check the cookie section you can see two cookies
__RequestVerificationToken
.ASPXAUTH
.ASPXAUTH is the cookie that FormAuthentication consume to do the authentication. For all following requests to the server, the server will check this cookie to authenticate user.
You can specify "Remember me" when you login which will changes the life span of this cookie, if you don't tick it the life span is tied up to current session, if you tick it depends on the settings on the server side.
Related
Is there a way to remove the authentication cookie, or sign a user out once they are removed from the asp.net membership database? By default if a user is removed from the database, the user can still browse the website since they still have a valid authentication cookie.
I've tried different things within global.asax but nothing seems to work. Is something like this even possible?
See here: FormsAuthentication.SignOut Method. Although this refers to users not being logged out server side, a similar approach can be used for managing deleted users.
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie. To improve security when using a forms authentication cookie, you should do the following:
Use absolute expiration for forms authentication cookies by setting the SlidingExpiration property to false. This limits the window in which a hijacked cookie can be replayed.
Only issue and accept authentication cookies over Secure Sockets Layer (SSL), by setting the RequireSSL property to true and by running the entire Web site under SSL. Setting the RequireSSL property to true ensures that ASP.NET will never send an authentication cookie to the browser over a non-SSL connection; however, the client might not honor the secure setting on the cookie. This means the client might send the forms authentication cookie over a non-SSL connection, thus leaving it vulnerable to hijack. You can prevent a client from sending the forms authentication cookie in the clear by running the entire Web site under SSL.
Use persistent storage on the server to record when a user logs out of the Web site, and then use an application event such as PostAuthenticateRequest event to determine whether the current user was authenticated with forms authentication. If the user was authenticated with forms authentication, and if the information in persistent storage indicates the user is logged out, immediately clear the authentication cookie and redirect the browser back to the login page. After a successful login, update storage to reflect that the user is logged in. When you use this method, your application must track the logged-in status of the user, and must force idle users to log out.
The third option is the most secure but requires the most effort. IMO, the first two do not resolve the issue adequately.
It is also possible to store custom information in the Forms Authentication Ticket. You could store the last explicit logout time in this ticket, and check it against your server side database record. Please note that if this record is at user level instead of session, then all logins under that account would be logged out at the same time.
In your case, if you are deleting server side user and session records, as the record does not exist you will be able to also fail the authentication request.
I'd advise also storing and checking the last date/time the password was changed - that way if a user updates their password then all existing sessions are logged out.
Instead of using ASP.NET MVC User's system, I'm simply using session, as the following:
When he logs in (username + password), I fetch the corresponding user from the Database and set:
Session["UserId"] = fetchedUser.UserId;
Then, I'm always checking if he is logged in:
if (Session["UserId"] != null && ...)
The problem is that if someone copies the value of ASP.NET_SessionId from a logged in user (eg: user goes to bathroom and coworker who is sitten next to him checks his cookies with chrome inspector), then he will be able to create a cookie in his computer and act as that user.
My questions are:
Why are sessions safer than cookies if the session id is saved in a cookie?
Can I make this safer (and continue using session)?
How does internally ASP.NET User authetication system do it?
A primary reason for not using Session as an authentication mechanism is that it could render your application vulnerable to Session Fixation. For example, a problem could be if a user arrived on your site using the HTTP protocol and receives a session ID that is stored in the ASP.NET_SessionId cookie. The user may later log in, and even though your login pages might be secured under HTTPS the session token has already been generated under HTTP which means it has already been transported using cleartext.
To answer your other points:
Why are sessions safer than cookies if the session id is saved in a
cookie?
The data stored in session is stored server side, so it is more difficult for an attacker to tamper with this data. All the cookie stores is a token for this data, rather than the data itself. Having said that, it is still safer to use the FormsAuthenticationProvider as this creates a new authentication token once login is complete rather than on session start for the reasons of avoiding session fixation as above.
Can I make this safer (and continue using session)? How does
internally ASP.NET User authetication system do it?
The built in provider is already fit for purpose, so it would be desirable to use that rather than fudge another mechanism to meet your requirements. It is also easily extensible so you can customise it to your needs. The ASP.NET User Authentication creates an encrypted ticket and stores it in the cookie rather than storing a reference to a server side variable: http://support.microsoft.com/kb/910443
I would also draw your attention to the signout mechanism and how to secure it. Particularly
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.
Details here: http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.signout.aspx
In addition you may want to set the "secure" flag on your ASP auth cookie to prevent it being leaked over HTTP by a MITM attacker.
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
Hi,
I need to determind how my site uses Cookies to inform the user in proper way.
The solutio is a ASP.NET MVC website using .NET Membership. Im storing data in sessions on server but nothing is saved manual to cookies on the client. I Supose however that the ASP.NET Membership is using cookies (for autologin) but im not sure witch data it really stores on the client?
Could you pleas explain or give me a link for this?
BestRegards
The forms authentication ticket (the cookie on the client) stores values such as the username and cookie expiration time along with some other boolean fields related to the remember me checkbox and sliding expiration. This is if you use cookie-based forms authentication which is the default and a typical choice. More information can be found at the following site:
Forms Authentication Explained
It is important to note that sessions and the forms authentication ticket (cookie) are not related in any way. You can have a session without being logged in and you can login and never touch the session object. This is an important difference.
EDIT
This cookie is not used for 'auto login'. After authentication, putting in a username and password, the cookie is created and is used for authorization - can you access these resources - throughout your site.
ASP.NET Membership enabled sites will have up to 3 cookies:
Session token
Authentication token
Roles cache (if enabled in
web.config)
To see them, open your site in the browser of your choice, login, and inspect the cookies. In IE its Tools -> Internet Options -> Settings (next to Browsing History) -> View Files
From what I understand about the way session hijacking works I don't see any advantage that Forms Authentication has over storing user authentication info in the ASP.NET session. Both Forms Authentication and ASP.NET session use cookies that are both hashed to verify integrity but both can't protect against a hacker stealing the cookie and masquerading as the user. So is there any reason as far as security is concerned, for using Forms Authentication over storing authentication info in the ASP.NET session?
Couple of differences:
If you store authentication information in session state and the app pool recycles, all of your users are instantly logged out. In contrast, forms authentication holds the necessary information in encrypted format in the forms authentication cookie, and will survive app pool recycle.
Session IDs are a 120-bit random number. The only protection is the randomness. There is no tamperproofing and in fact a hacker could continuously poll your web site with random session IDs until he finds one that works. There is no intrusion detection mechanism for this sort of activity, because it is impossible to distinguish a tampered session ID from an expired one.
The forms authentication ticket (cookie) is completely different. It is composed of a long string of data that is then encrypted with your 128-bit machine key. If anyone tampers with it it simply won't decrypt. The failure to decrypt is a trappable error and can be enlisted in intrusion detection mechanisms. The overall cardinality of the ticket is much higher and harder to brute force.
On all the sites I have worked with recently, we actually use BOTH the forms authentication mechanism and the ASP.NET_SessionId. We also have an internal session ID (an ESB session identifier) that we insert into the forms authentication ticket.
The only interesting argument I heard for using Forms Authentication instead of storing authentication info in Session was that I could put more restrictions on the Forms Auth cookie (expiration date, etc.) but not on the Session cookie. So things like user preferences or whatever would persist in session and not be lost if the user is forced to login again after 30 minutes. Yeah, I don't know