31. August 2011 20:14
I was reading here about how it's a bad idea to log into your application using SSL (https) and then revert back to http for subsequent pages. If you do that then you'll send the authentication token over an unencrypted connection, which is a bad thing.
Whilst wondering if there was an easy way to solve that problem, I wrote some code to try and enforce a secure connection whenever the user was authenticated. So I wrote my own [RequireHttpsWhenAuthenticatedAttribute] which inherited from [RequireHttpsAttribute]. The idea was that you apply it to your whole site from your global.asax, and then https will *automatically* be turned on (and enforced) when users are logged in.
After posting that code, I got an e-mail from Andy Brown (thanks Andy) pointing out that if a logged in user switches to http by editing the address in their browser, the cookie will have already been posted back to the site by the time my new attribute is able to do anything. To be totally safe you'd have to assume that the cookie is already compromised at that point. I then realised that even if the site signs them out, the cookie could still be used by a hijacker until it times out. For example, this article says “Even after the user has logged out of the application and the developer has called FormsAuthentication.SignOut, the authentication ticket remains valid until its time-to-live (TTL) expires, so it can be used by an attacker to impersonate another user.”
So I went back to the drawing board to try and find an even better way.
In the end, the best option seems to be simply using this option when you set up forms authentication in your web.config:
Rather than refer to your whole site, this attribute just applies to the authentication cookie, meaning the the browser should only send the cookie over https. Using that setting does the same job that my code was trying to do, only better. So I don't need any special code after all.