It is a Plain ASP.NET application using SQL Membership Provider for authentication. While application runs good most of the time. We have recently seeing complains from users saying they are seeing other users account.
I am pretty sure & confirmed again I directly consume HttpContext.Current.User.Identity.Name in the code to get user information. So under heavy load I get different user name returned.
Has anyone faced similar issue ? Have possible cause ?
Application Runs in ASP.NET 4.0, Web Forms , No caching ,Not handled any cookies in code, no Javascripts that is sniffing cookies.
I see these two links taking about same but no answers posted.
http://bytes.com/topic/asp-net/answers/324385-serious-issue-httpcontext-current-user-identity-name
http://www.experts-exchange.com/Web_Development/Miscellaneous/Q_21105924.html
Forms Authentication shouldn't be related to Membership provider too much.
FormsAuthentication saves signed user information into .ASPXAUTH cookie. And when next request comes to server, it decrypts cookie value and set it back to HttpContext.Current.User.Identity.Name. It uses MachineKey for encryption\decription. Then it creates FormsIdentity object based on FormsAuthenticationTicket object that holds username. So, your userName is stored on client. And whole this process doesn't include usage of Membership provider.
Forms Authentication uses Membership only when you do login for user, and then based on logged in user FormsAuthentication creates a cookie with UserName.
About your problem, you need to check .ASPXAUTH cookie value for those requests who has invalid UserName. You can try to log cookie information for these bad requests, and then you can decrypt them to get userName info from request. Or if you can reproduce it locally you can disable Forms cookie encryption (protection element), and then check it's value for bad requests
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.
I'm building web portal in ASP.NET MVC 3 that uses distant web service as only way to communicate with database. Web service has requirement to always have Username/Password passed in request header, otherwise it rejects the call.
I have overridden ASP.NET Membership so that my ValidateUser method sends Username/Password to web service Login method, and returns true/false if authentication is successful. It works quite nice with AcountController provided with MVC 3 Empty internet template. Since I have to pass Username/Password on every web service call, I'm saving them in Session.
My problem is:
If I close browser and reopen it... I remain logged to website, but my Session variables are expired, so none of my requests to web service are being accepted, even though I'm still logged with credentials.
I'm looking for nice suggestion how to sync user logged in state with session state. Either to keep them both persistent until log off is used or to have them both dispose on browser being closed.
Thanks for all suggestions :)
When the user signs in using your AccountController, try setting the auth cookie like this:
FormsAuthentication.SetAuthCookie(model.UserName, false);
This should tell ASP.NET to delete the cookie when the browser window is closed. Then, when user opens up a new browser, both the session and the auth cookie should both be destroyed.
Sessions are cookies on the client side. Forms Authentication (which uses your membership provider) also uses cookies.
They are different.
Is your auth ticket or cookie persistent? This MS KB will explain things and scenarios in more detail than I would here...
Hth.
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
I'm writing an ASP.net application that uses Windows Identity Foundation. My ASP.net application uses claims-based authentication with passive redirection to a security token service. This means that when a user accesses the application, they are automatically redirected to the Security Token Service where they receive a security token which identifies them to the application.
In ASP.net, security tokens are stored as cookies.
I want to have something the user can click on in my application that will delete the cookie and redirect them to the Security Token Service to get a new token. In short, make it easy to log out and log in as another user. I try to delete the token-containing cookie in code, but it persists somehow.
How do I remove the token so that the user can log in again and get a new token?
I found the solution. To put it succinctly:
Dim smartWsFederationAuthenticationModule As _
Microsoft.IdentityModel.Web.WSFederationAuthenticationModule = _
HttpContext.Current.ApplicationInstance.Modules("WSFederationAuthenticationModule")
smartWsFederationAuthenticationModule.SignOut(True)
See here for more information: http://garrettvlieger.com/blog/2010/03/refreshing-claims-in-a-wif-claims-aware-application/
I also see that I can get handles to some other parts of the WIF framework this was, as well. It's definitely worth the read.
Cookies are a bit strange. They are managed by the browser and there is no "Method" to delete them. Just deleting them from the Request or Response objects on the server side does not remove them from the browser on the client side.
To "Delete" a cookie you have to set it's expiration date to the past.
See: http://msdn.microsoft.com/en-us/library/ms178195.aspx