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
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.
I have created an STS and a relying website that is able to authenticate using the STS via WIF. In all browsers but IE9 this works well. In IE9, after logging in and using the relying website for about 5 minutes (not consistent, but usually happens after 5 to 10 minutes) the user is redirected back to the STS to sign in again.
However, the user is not really signed out of the STS. If the user simply refreshes the sign in page of the STS, a new tab opens and takes them back to the relying website.
I am very puzzled by this behavior, and can only reproduce it in IE9. Any ideas what might be causing this?
It sounds like your session cookie is expiring too early. Can you check your site's web.config and see what persistentSessionLifetime you have set in the cookie handler (if any)?
This post has some detail:
How do I increase session timeout with W.I.F / SAML tokens / FedAuth cookie
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've got an asp.net application which seems to forget that a user is logged in after a while.
I'm using the membership provider and when opt to "remember" the log in it remembers it during the session. I can even close the browser, restart and come back and it will still be logged in. But after a while it forgets and it seems to do it at any old time. I've once been logged in and when I went to a new page it was logged out.
The other strange things are:
On my development machine it remembers the log in forever. Even after IIS restarts and recompiles it will remember my login as expected.
I have another application on the same server that does remember the login forever. I compared how they handle login and they seem to be identical.
This leads me to believe that the issue has something to do with the server or perhaps something in the application not directly related to the login and membership code. What could I look at?
Edit:
Looked up the cookie using Fiddler and they seem to be ok.
An Authentication cookie created today expires 2 weeks from now, which is how my config is set up:
expires=Mon, 06-Sep-2010 01:47:51 GMT
Edit:
The problem seems to be that the app pool is recycling and the authentication cookie becomes invalid because it can no longer be read as the machine key has changed. The solution was to add a machineKey segment to the web.config and supply a static machine key.
There are two major possibilities.
Cookie expiration. If the cookie expires / goes away, then you are considered logged out.
Cookie invalidation. Login cookies are encrypted based on the machineKey value. If you do not specify a machineKey, a new one is regenerated each time the application pool starts up (or is recycled). That means that any login cookie encrypted with the old machineKey is now invalid, and you will not be considered logged in.
Check to see what the recycle settings are on your application pool in IIS and see if that corresponds with the timing of you not being logged in.
"Remember me" functionality is done using cookies. Cookies can be set with an expiration date. You need to look into how the cookie is being set (Fiddler is good for this, you can inspect the HTTP header when the cookie is set.)
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!