8

Some parts of my website are only accessible via HTTPS (not whole website - security vs performance compromise) and that HTTPS is enforced with a 302 redirect on requests to the secure part if they are sent over plain HTTP.

The problem is for all major browsers if you do a 302 redirect on POST it will be automatically switched to GET (afaik this should only happen on 303, but nobody seems to care). Additional issue is that all POST data is lost.

So what are my options here other than accepting POSTs to secure site over HTTP and redirecting afterwards or changing loads of code to make sure all posts to secure part of website go over HTTPS from the beginning?

c2h5oh
  • 4,492
  • 2
  • 23
  • 30

2 Answers2

7

You are right, this is the only reliable way. The POST request should go over https connection from the very beginning. Moreover, It is recommended that the form, that leads to such POST is also loaded over https. Usually the first form after that you have the https connection is a login form. All browsers applying different security restrictions to the pages loaded over http and over https. So, this lowers the risk to execute some malicious script in context that own some sensible data.

Serge
  • 6,088
  • 17
  • 27
  • True in general, but in this particular case the data send, while goes to the secure part of the site is of little importance and easily escaped (just an integer + anti csrf token). That's why I'm even considering a workaround instead of a proper fix. – c2h5oh Sep 23 '12 at 00:12
  • Please, see the note in the other answer about what is sensitive data from your and user's points of view. – Serge Sep 23 '12 at 00:14
2

I think that's what 307 is for. RFC2616 does say:

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

but it says the same thing about 302 and we know what happens there.

Unfortunately, you have a bigger problem than browsers not dealing with response codes the way the RFC's say, and that has to do with how HTTP works. Simplified, the process looks like this:

  1. The browser sends the request
  2. The browser indicates it has sent the entire request
  3. The server sends the response

Presumably your users are sending some sensitive information in their post and this is why you want them to use encryption. However, if you send a redirect response (step 3) to the user's unencrypted POST (step 1), the user has already sent all of the sensitive information out unencrypted.

It could be that you don't consider the information the user sends that sensitive, and only consider the response that you send to be sensitive. However, this turns out not to make sense. Sensitive information should be available only to certain individuals, and the information used to authenticate the user is necessarily part of the request, which means your response is now available to anyone. So, if the response is sensitive, the request is sensitive as well.

It seems that you are going to want to change lots of code to make sure all secure posts use HTTPS (you probably should have written them that way in the first place). You might also want to reconsider your decision to only host some of your website on HTTPS. Are you sure your infrastructure can't handle using all HTTPS connections? I suspect that it can. If not, it's probably time for an upgrade.

Samuel Edwin Ward
  • 6,526
  • 3
  • 34
  • 62
  • Note from RFC2616:"RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location [..]" so standard-wise it's the browsers fault - they do that for historical reasons and I have no choice but to live with it. – c2h5oh Sep 23 '12 at 00:02
  • As for serving whole website over HTTPS I'm not worried about performance on my side. What worries me is the 3-packet handshake on new https connection (with a single server location and users spread over a very large area this translates to up to 1 second extra on 1st request), one request for main site and one per each of the 3 cdn nodes. Simulated difference of 1st page load was in 0.5 up to 2.1 seconds and with this being an eCommerce site that's a significant delay, one that can cost me real money. – c2h5oh Sep 23 '12 at 00:08