2

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?

Community
  • 1
  • 1
JonHendrix
  • 933
  • 15
  • 28

2 Answers2

3

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?

Brad Wilson
  • 67,914
  • 9
  • 74
  • 83
  • Hi Brad, thanks for your response. Two reasons why we mix http and https. First, it's an application from which also images are served to e-mail messages. Images used in HTML e-mail messages are better not send over HTTPS due to compatability issues. Also, because we serve these images over a non-ssl connection, a popup would appear within the application asking the users if they allow mixed content. These same images for the e-mail messaged are used within the application. – JonHendrix Apr 14 '11 at 06:46
  • Second, assets (CSS, JS, images etc.) aren't cached when deliverd over SSL. Which means every request sends a lot of assets each time. Although this could be solved by doing a bit of redisign and optimalization, I still think the application will respond and act better when most resources are cached. – JonHendrix Apr 14 '11 at 06:46
  • I'm really only talking about the application itself, not the assets. Being able to serve images over both SSL and non-SSL shouldn't be a big issue, presuming that the non-SSL images that are being served don't require authentication to view (since they're being embedded into e-mail messages, I'm guessing they don't). – Brad Wilson Apr 14 '11 at 16:53
  • SSL shouldn't prevent caching. It should be orthogonal to caching. – Brad Wilson Apr 14 '11 at 16:53
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.

RickAndMSFT
  • 20,912
  • 8
  • 60
  • 78