While working with ASP.Net Forms Authentication I came across the .ASPXAUTH cookie. I have a couple questions:
What is the purpose of this cookie?
What is the location of this cookie?
The ASPXAUTH cookie is used to determine if a user is authenticated.
As far as the location of the cookie, that depends on your browser. If you are using Firefox you can view the cookie by clicking on Tools -> Options -> Privacy. Then scroll down to the domain and expand it to see the cookie and its value. The value is encrypted using the machine key (located in the server's machine.config or web.config file) so looking at the cookie on the client won't really provide you any information. You can decrypt/view the value on the server side using:
HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];//.ASPXAUTH
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
where authTicket has these fields:
The statement "ASPXAUTH is basically used to maintain ASP.NET Session State" is incorrect. ASP.NET issues an entirely different cookie, named ASP.NET_SessionId, to track session state.
Actually the .ASPXAUTH cookie does not accurately tell you when the user is truly authenticated. When the user logs out of the app, the .ASPXAUTH cookie is removed from the browser. However, if you go back to the site within a short period of time (with timeout of form auth cookie), and edit the new ASP.NET_SessionId cookie's with the following:
change "name" field from "ASP.NET_SessionId" to ".ASPXAUTH"
change "value" from 24 char sessionID to old 448 char authentication string
After refresh you will be able to assume the identity of the authenticated user without technically re-authenticating again. (again assuming you do this within the specificied timeout stored within the .ASPXAUTH encrypted auth string)
A good blog post explains the problem in more detail. A possible solution is to couple the .ASPXAUTH with the ASP session.
on Chrome Browser
1.developer tools -F12
2.locate Application tab
3.point the left pane for cookies
you will find it out if ASPXAUTH cookie for the available session on logged in applicaion
Related
I think that internal mechanism of authenticaton should set a cookie with a token and store the same token on a server and next on every request compare the tokens from the cookie and on the server and if they are equal then user is logged in. I don't know where a server stores token, maybe in Session or something else (not persistent), but I'm sure that after the server's restart the server's tokens's store should be cleaned up therefore a user with an old cookie can't be authenticated. But in a practice after I restart my server a user is still authenticated and have access to pages because User.Identity.IsAuthenticated returns true. It seems to me wrong. Even if I remove this user from my DB (I use Membership) because I don't want this user have access anymore and restart my server, the user is still authenticated. Can anyone explain this?
Source of answer
Here is how authentication process works.
You setup some stuff in your web.config around where the login page is, how long the login is good for and whether or not to use sliding
expiration (should the time be extended if the user is active on your
site)
User comes to your site, enters their username and password.
That information is posted to your server. You take that information, verify that it is correct (authenticate). If it is
correct, the server then issues an encrypted cookie known as the
FormsAuthenticationTicket Note - this could have a different name in
the new Identity stuff, but the same principle.
The cookie's contents includes items such as the user name and expiration date of the login.
On each request, the server looks at the cookie collection for the authentication cookie. If found, it decrypts it, reads the values and
determines if this is still a valid cookie (expiration time). Once it
has the user information from the cookie, the server can use this
information to determine if the user is authorized for the resource
requested (look up by username).
If the cookie is not present, or has expired, or When the user logs out, the cookie is deleted from the cookie collection. Now, if the user tries to go to a resource that is for authorized users only, then the user is redirected back to the login page.
Hope this helps.
Can't we just store in the session if the user is logged in or not and get rid of the .ASPXAUTH?
ASP.Net_SessionId is a cookie which is used to identify the users session on the server. The session being an area on the server which can be used to store data in between http requests.
For example, the controller action may perform:
Session["FirstName"] = model.FirstName;
Then, in a subsequent action the first name can be retrieved from the session:
var firstName = Session["FirstName"];
The ASP.Net_SessionId identifies the session for that users request. A different user will submit a different cookie and thus Session["FirstName"] will hold a different value for that different user.
ASPXAUTH is a cookie to identify if the user is authenticated (that is, has their identity been verified). For example, a controller action may determine if the user has provided the correct login credentials and if so issue a authentication cookie using:
FormsAuthentication.SetAuthCookie(username, false);
Then later you can check if the user is authorised to perform an action by using the [Authorize] attribute which checks for the presence of the ASPXAUTH cookie.
So in summary, the cookies are there for 2 different purposes. One to determine the users session state and one to determine if the user is authenticated.
To complete the answer to your question, yes, you could get rid of the ASPXAUTH cookie and just use session to identify the user (I have seen this done in older classic asp applications) but I wouldn't recommend it. It is much better to have a cleaner separation of concerns and use the appropriate method where necessary. The session and authentication will have their own time-out values set. By using the session for authentication you will only have the single time-out. I'm not sure though if there are any security implications in just using session for authentication, but still I would keep them separate.
.NET issues an entirely different cookie, named ASP.NET_SessionId, to track session state.
The ASPXAUTH cookie is used to determine if a user is authenticated.
So these are 2 different concept i.e. Session State Management and Authentication Management using Form Authentication.
If you use Session to Authenticate and forget Form Authentication you will get rid of .ASPXAUTH
Both are required , using either resulting in the following vulnerability:
*ASP.NET_SessionId Alone: Session Fixation
*Forms Authentication Cookie Alone: Can’t Terminate Authentication Token on the Server
Also, you need to ensure they coupled together properly.Otherwise, the configuration also pose risk:
*Loosely Coupled ASP.NET_SessionID and Forms Authentication Cookies: Still Vulnerable
ref:
http://blog.securityps.com/2013/06/session-fixation-forms-authentication.html
Session state and authentication have nothing to do with each other. You can use one without the other.
This morning me and my co-worker went on discussion about storing auth cookie when
RememberMe = false.
MVC4 , Forms Authentocation, C#.Net, Visual Studio 2012, IIS 7.5 , InProcess Session
User LogsIn,(RememberMe = false) and Navigates to an item in the app.Default session timeOut was set 30 mins,
User Copied the URL and Closed the browser(IE9)
Opened new browser(IE9) and Pasted the Copied URL, UI redirected to loginPage.
Here I say session created in step 1 is still valid., On close of the browser , browser lost the AuthCookie.
He says that that Session is created based on browser session also. I'm bit confused.
Please let me know what actually happened.
Sorry for the bad English
RememberMe = false means the authentication cookie that was issued to the user was NOT persistent (the expiration of the cookie is set to "SESSION"). That is, the cookie is lost when the browser session ends. RememberMe = true means a persistent cookie is created and is saved across multiple browser sessions(the expiration of the cookie is set to a specific date, usually configured in web.config).
Read the documentation here
I'm assuming you're using the default Session-State Mode, which is InProc. A session generates a SessionID and this ID is stored in a cookie. This cookie is sent to the user and whilst requests are made with that cookie, the session is alive. The ID itself identifies the unique browser, which is why you can log into the same website with different accounts when you use two different browsers at the same time. However, you can't sign into different accounts from different tabs of the same browser (unless the website has specifically customised their site to support that feature).
By closing the browser, this cookie is deleted, and so the session will be ended when its timeout period has been reached. The reason you're taken to the UI page is because the new cookie you have no longer has the same session ID so, for all intents and purposes, you're a new user.
When a user logs in through my login page, I authenticate them using FormsAuthentication, and set some Sessions that holds user specific info, like UserID and RoleID. I set site content based on these values.
The problem is when the session expires and the user is still signed in - things are messed up, because the session is null but the user is still signed in.
How can I keep them in sync with each other, so the session only expires if they're signed out or vs.
Thank you.
When the session has ended (Session_OnEnd) in global.asax, you can kill the forms authentication cookie. Doing so will redirect the user to the default page (or login page depending on how you set it up) upon any subsequent requests. You should also kill the authentication cookie when user has manually logged out - same effect.
To kill the authentication cookie:
FormsAuthentication.SignOut();
I use a ASP.Net login control in a straightforward manor however I have spotted that the ASPXAUTH cookie has an expiry date of {01/01/0001 00:00:00}. Should this not get to something to prevent hacker manipulation? I am not issuing the cookie myself I am letting .Net create it.
I have run a scan on my web app and it is able to store the ASPX cookie information, go to the log out page and then go to a page without a need to login I assume using the stored cookie information.
Using the application manually I am unable to do this, it always sends me to the login page when trying to access the page.
The logout page calls FormsAuthentication.SignOut()
EDIT: Turns out this is a known problem! Who knew! http://support.microsoft.com/kb/900111
You cannot read the cookies expiration date and time. The browser uses the cookies expiration date to determine whether or not to send the cookie to the server. If a cookie has expired, the browser does not send that cookie to the server with the page request, the cookie is deleted.
If the cookie has not expired the cookie is sent to the sever sans expiration information, since this information is utilized by the browser to determine if the cookie should be sent or not. You can read the expiration date from the request, but as you have discovered it returns a date time value of zero.
Try checking the expiry date of Response.Cookies collection in the LoggedIn event. This should yield the correct expiry date of the cookie.
protected void Login1_LoggedIn(object sender, System.EventArgs e)
{
HttpCookie cookie = Response.Cookies(".ASPXAUTH");
DateTime expires = cookie.Expires;
}
See Basics of Cookies in ASP.NET for more information.
If you save the value of the cookie, log out, and then re-present that cookie to the server, it will just log you in automatically as if you had never logged out.
This is because you can also tell the .NET framework to set a persistent authentication cookie (by default you can present this option to the user with the "Remember Me?" checkbox exposed with the DisplayRememberMe property of the Login control) so the expiry date would be a value in the future.
When the user comes back to the site and their browser sends the cookie, they are automatically logged in - so the behaviour you're seeing is be design.
If you need to be more secure, the easiest thing to do is add a method to the OnLoggedIn event of the login control, and set a session value (i.e. Session.Add("HasLoggedIn", true)) that you can then check elsewhere, and if it's not true, redirect to the login page:
if (null == Session["HasLoggedIn"] || !(bool)Session["HasLoggedIn"]) {
FormsAuthentication.RedirectToLoginPage();
}
Edit to respond to comment:
Which is why you're seeing the expiry date of 01/01/0001 00:00:00 - this will be deleted at the end of your session - or when you close the browser - but there's nothing fundamentally wrong with what you're seeing - just because you're not setting a persistent cookie doesn't mean that if you send a copy of an old cookie back to the server it won't log you in with it.
As I said, if you want to ensure that users have to log in each time (or to "resolve" this issue), add a session variable that you set when the user actually logs in, and reject all requests without it.
Further edit for second comment
From Explained: Forms Authentication:
Each time a subsequent request is received after authentication, the FormsAuthenticationModule class retrieves the authentication ticket from the authentication cookie, decrypts it, computes the hash value, and compares the MAC value to help ensure that the cookie has not been tampered with. Finally, the expiration time contained inside of the forms authentication ticket is verified.
Note ASP.NET does not depend on the expiration date of the cookie because this date could be easily forged.
So the cookie has to sent back to the server before the ticket has expired.