asp.net use requireSSL and still be able to check if the user is authenticated on Non-SSL pages

Question

I have a webapplication (asp.net 3.5) with mixed SSL. All account related pages are delivered over SSL. Mostly all other pages are delivered over non-ssl. To automatically switch between HTTPS and HTTP I use this component. Lately there was a news item regarding the ability toch hijack user sessions on non-secure Wifi networks. This should be possible by catching the Cookie that is transmitted over non-ssl connections.

This triggered me to review my security choices in this webapplication. I've (again) grabbed this article from MSDN and tried the requireSSL=true property on my Formsauthentication. Before I've even started the webapplication I realized that my User.Identity will be null on non-SSL pages because the cookie containing this information isn't sent from and to the webbrowser.

I need a mechanism that Authenticates the user over a SSL connection... and remembers this authentication info, even on non-SSL pages.

While searching SO, I've found this post. It's seems to me that this is a good solution. But, I wonder if a solution can be found in storing login information in the Sessionstate? I'm thinking of catching the Application_AuthenticateRequest in the Global.asax. Checking if the connection is secure and check either the authcookie or Session. I don't know exactly how I'm going to implement this yet. Maybe you can think with me on this?

Answer 1

Unfortunately, you have conflicting requirements. You can't have a secure session over non-SSL, so I'd like to challenge your underlying assumption: why not have the whole site use SSL?

Answer 2

From the MVC FAQ (similar question answered by security guru Levi) asking for an attribute to not use SSL.

•The [RequireHttps] attribute can be used on a controller type or action method to say "this can be accessed only via SSL." Non-SSL requests to the controller or action will be redirected to the SSL version (if an HTTP GET) or rejected (if an HTTP POST). You can override the RequireHttpsAttribute and change this behavior if you wish. There's no [RequireHttp] attribute built-in that does the opposite, but you could easily make your own if you desired.

There are also overloads of Html.ActionLink() which take a protocol parameter; you can explicitly specify "http" or "https" as the protocol. Here's the MSDN documentation on one such overload. If you don't specify a protocol or if you call an overload which doesn't have a protocol parameter, it's assumed you wanted the link to have the same protocol as the current request.

The reason we don’t have a [RequireHttp] attribute in MVC is that there’s not really much benefit to it. It’s not as interesting as [RequireHttps], and it encourages users to do the wrong thing. For example, many web sites log in via SSL and redirect back to HTTP after you’re logged in, which is absolutely the wrong thing to do. Your login cookie is just as secret as your username + password, and now you’re sending it in cleartext across the wire. Besides, you’ve already taken the time to perform the handshake and secure the channel (which is the bulk of what makes HTTPS slower than HTTP) before the MVC pipeline is run, so [RequireHttp] won’t make the current request or future requests much faster.