I am creating some cookies in my ASP.NET application. These cookies expire 10 minutes after they have been created. I follow the approach described on MSDN as shown here:
http://msdn.microsoft.com/en-us/library/system.web.httpcookie.expires.aspx
My question is, when a cookie "expires", what happens? Does the browser automatically delete the cookie? Is it our responsibility as developers to remove the cookies if they exist and have expired?
Thank you,
Does the browser automatically delete
the cookie?
Yes - or earlier if the user wants to.
Is it our responsibility as developers
to remove the cookies if they exist
and have expired?
No - it's the Browsers responsibility
You should only worry on setting the expiration, the client handles the rest.
You should not rely on the browser to delete old cookies. The browser will delete cookies by comparing the expiration date to the time on the client PC, not the server. So if you're setting the expiration server side for 30 minutes from now, but the client has there clock 1 year behind, then the client's browser won't delete the cookie for another year and 30 minutes.
Always check the expiration server-side before authorizing the request!
Related
I'm using a single login page that uses form authentication. This page creates a domain cookie on mysites.com.
I have three other websites which require the authentication to access. In my page loginsso.mysites.com I have my cookie expiration set to 30 minutes. However what happens is when that cookie expires it will kick the users out of my other three sites.
To make this more complicated each of those 3 sites has an idle time out.
So this is how it works:
The user logs into mysso.mysite.com
it creates a domain level cookie (this cookie has a 30 minute timeout expiration)
-mysitea.mysite.com has a 3 idle hour expiration
-mysiteb.mysite.com has a 1 idle hour expiration
-mysitec.mysite.com has a 2 idle hour expiration
So the user who's logged into mysso.mysite.com and navigates over to mysiteb.mysite.com and is working there for 30 minutes will no longer be able to access the site after 30 because of the cookie specifications on mysso.mysite.com.
Basically I need a way to handle this. If a user navigates to mysiteb and works he's not idle and should not be kicked out of mysitesso.
Hope this makes any sense.
It's also possible I am mixing SessionTimeOut with CookieExperation and how they are handled.
In your case, use a session cookie for both the SSO and the individual applications. A session cookie is a cookie that doesn't have an expiration date set – it will stay around until the browser is closed (for details, see here). Handle session expiration for all the applications in server-side logic, and destroy the session when a timeout occurs.
You should also make sure that the session cookie is protected from javascript access to prevent XHR attacks (which works in all modern browsers). You can do this like here:
cookie.HttpOnly = true;
More documentation about the HttpOnly attribute can be found in the documentation, or an in-depth article about form authentication by looking for HttpOnly.
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.
I have couple questions about security in ASP.net and in general.
Where are stored "Authorization" cookies? When I logined in the system and then decided to logout I suppose for this enough to delete cookies from my browser but this not work. Then I rethink that these cookies is supplied from browser stored passwords, but wrong again, since I don't see login/password info for my site there.
And since "Authorization" cookie is always returned in response for 401 code, user stays always logined in the system and I can't understand how to logout.
The timeout for ".ASPXAUTH" - 30 min is recommended, and then cookie expired. Though I login, then after recommended 30 minutes I need to login again (even with sliding property to true, I can just leave a page for more than 30 minutes). But when I login to the most of the sites (such as stackoverflow for example), I can enter here again without logining even after week delay. How it is implemented, is that sites just set timeout for much bigger timespan or there is some other techniques?
Thanks!
Answer to question 1:
Use FormsAuthentication.Signout(); to logout. This will delete the authentication cookie. The authentication cookie is stored in the http-request and in the response as every other cookie.
Rergarding your 2nd question: Your cookie should expire after 2880 minutes. I don't know why it expires after 30 minutes in your case. Also the sliding expiration normally works. Could your browser settings have some influence? Another possiblility could be that the Visual Studio internal web server does not behave like a real web server. Try your settings on IIS.
EDIT:
I think the answer to your 2nd question is here
I say until you log out, session times out or you close the browser. But am I right?
I had an interview today and the interviewer wanted to know if I log into a page and closes the browser (without logging off), what happens to the session.
I said that the session will be orphaned. He says no - because their users are able to connect back to the session by just opening up the browser (using a cookie only). I told him that's a persistent cookie - not a session cookie.
And I said that if that's the cause, there is nothing preventing the user from exporting the [persistent] cookie to a another computer and starting the session on that computer.
At first he said you can't export a cookie but when I explained how, he said that he'll look but since many many people including 2 architects came up with the design, it is unlikely they are all wrong.
A session cookie is a cookie without an expiration time.
Handling of session cookies varies by browser and by browser version, but generally cookies that have no expiration date are deleted when the last instance of that browser is closed (lifetime=runtime of the browser).
Importantly, the server-side session that corresponds to the cookie value has a completely independent lifetime that is defined on the server. HTTP is a connectionless protocol, so when your browser isn't in the middle of a transaction, the server side has no idea whether you're still there or not. Tomcat issues unique, fixed-length cookies named JSESSIONID that they link to stored session data on the server. In that case the session expiration time is stored on the server. ASP base64 encodes all the session info, encrypts it, and writes it to giant cookies in your browser so it doesn't have to store that session data on the server. The session expiration time is saved inside the encrypted data stored in the cookie. Either way there's a record of when the session should expire, so session lifetime can't exceed the server side timeout.
You can set the same cookies in another browser and send the same data (mostly cookies) that the first browser would have sent, and as long as the server timeout hasn't been reached, the server will let you access the server-side session the same way. When people do this to your cookies, it's called a session hijack.
Here's JavaScript code adding a "session" cookie, which is just a cookie where no "Expires" value has been set.
document.cookie="COOKIENAME=cookievalue";
Here's JavaScript that adds a cookie with a specific expiration time, meaning that the browser is instructed to stop sending it with outgoing requests after that time:
document.cookie="COOKIENAME=cookievalue; expires=Fri, 31 Dec 9999 00:00:01 GMT";
The cookie data sent to the server does not include metadata like expiration time; the server only sees the key=value pairs.
Expiration data is only for the browser to read.
Setting a cookie with either of the above methods will cause the browser to send that cookie to the server this way:
Cookie: COOKIENAME=cookievalue
The server initially sets the cookie with or without an expiration date, but it has no idea whether that has been changed, and it doesn't really care. There's no functional difference between a cookie set to expire next month and a session cookie on a computer that stays on with the browser running until next month.
You are absolutely right. Session cookies are deleted when the browser closes and persistent cookies are deleted when their expiration time is up. Their website must use persistent cookies if the sessions stays alive after the browser closes. All cookies can be exported to another computer. This is a well known security vulnerability that is mitigated by using SSL.
There isn't a clear definition of "session" in web applications. A web site may decide to use either persistent cookies or session cookies to look up a session context on subsequent requests (or maybe something besides cookies). If the session lookup is done through a session cookie, then what you said about the session being orphaned (on the server, not accessible by a client) is correct.
However, "when you close the browser" is ambiguous. If you have two instances of Internet Explorer open, for example, both windows may be keeping a session cookie alive. Therefore, closing "the browser" that the web site page is displayed in won't necessarily clear the cookie.
Not sure if it's the same as ASP, but I know that in PHP it's 20 minutes
Can anyone hijack (via js) the asp.net forms cookie and change the expire date?
What can stop them from grabbing it and changing the expire date? i.e. effectively letting the user stay logged in?
Update
Does the .net framework forms auth. cookie rely on the cookie's expiration date or does it encypt that?
There are a few things you can do to improve the situation.
In web.config, set protection="All" for the cookie: http://msdn.microsoft.com/en-us/library/1d3t3c61.aspx. This will encrypt and validate, making it harder to hack client-side.
Additionally, cookies can have httpOnly set to true. This tells the browser that the cookie cannot be manipulated in javascript.
The <forms> element in web.config also has a setting for timeout (see link above). It's possible that Microsoft's implementation is smart enough not to depend solely on the cookie, but I don't know.
The other comments are correct that the client should never be trusted. So to be airtight, you'll want to track "last login" on the server and force a new login after some time period.
Cookies are stored by the client, you can't trust them not to change.
There are extensions for Firefox that let you edit cookies, including the expire dates. If you want them to force them to expire you should be tracking them server side too and expire them there.
Track it server side.
Via JS (JavaScript) it is not possible, at least not in a browser that honors the HttpOnly attribute that ASP.NET sets for the Forms cookie.
well not sure about javascript but you can do it using Cookie Editor add on of Fire Fox
encrypt it
set a additional date flag inside the cookie
If you want to prevent this, hash the expiration date into the cookie value. Then, when you retrieve the cookie, if the hashed expiration date doesn't match the plaintext expiration date, discard the cookie.