15

We have a site that have redirection path like so:

  1. http://www.example.com
  2. http://www.example.com/
  3. https://www.example.com/

Notice how it goes from http to http first (added a /), then finally go to https

While ideally it should first go to HTTPS before adding a slash, it is what it is now. Moreover, user final destination is HTTPS so my thinking is it should be secure enough.

I would like to know if the above step would potentially raise any security concerns, and see if hardening is needed. Cheers!

5
  • 6
    I think 1+2 is just as safe as only 1; it's within your server, so the protocol doesn't much matter.
    – dandavis
    Jun 30 at 4:34
  • 5
    Do you have HSTS set?
    – nobody
    Jun 30 at 7:02
  • 3
    Yes, HSTS is set, thanks for asking Jun 30 at 8:28
  • Why do you redirect to "/"?
    – Salman A
    Jul 2 at 11:47
  • @nobody even HSTS doesn't save you )
    – LUser
    Jul 8 at 9:57
40
http://www.example.com
http://www.example.com/

There is actually no difference between these from the perspective of the browser and HTTP protocol. A URL consists (among others) of a protocol (http://), a hostname (www.example.com) and a path. An empty path is not possible and both of the URL shown use the path /. So there is no actual redirect between these URL since these are equivalent already.

For more on this see the HTTP standard, specifically RFC 7321 section 5.3.1: "If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target.". Note that this only applies to http://example.com vs. http://example.com/, i.e. empty path vs. /. With a path of /foo vs. /foo/ it is different since these will actually result in different requests.

Moreover, user final destination is HTTPS so my thinking is it should be secure enough.

Since the initial request and response are still done via plain HTTP, they are not protected against manipulation by a man in the middle. For example the response could be modified or a new response injected to direct the client to a different final URL. This actually happens, see for example Internet Provider Redirects Users in Turkey to Spyware: Report.

In other words: every clear text redirect is one too much. To reduce this attack vector further use HSTS.

18
  • 24
    @NgSekLong: RFC 7321 section 5.3.1: "If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. ". Also, just look at the wire (with wireshark or similar) and the servers log files to see what is actually happening regarding requests and redirects. Jun 30 at 4:52
  • 3
    @rexkogitans: May I introduce you to the actual standard? See RFC 7230 section 3.1.1 about the request line. The second element is request-target. This is defined in RFC 7231 section 5.3 where you have origin-form, absolute-form and others as choice. absolute-form is the one you refer too, which is (as explicitly stated) used when connecting to a proxy. For normal requests origin-form is used which starts with absolute-path. If you don't believe the standard you might also just look at actual traffic. Jun 30 at 19:16
  • 4
    @rexkogitans: This question is about redirecting a request of http://example.com to http://example.com/ and then redirecting the latter one again. The answer is that the first kind of request is exactly the same as the second request, which also means that the redirect of the first request to the second will never happen - it will be directly redirected to the third (remember: first and second can not be distinguished in the server). Jun 30 at 19:42
  • 3
    @rexkogitans: this is not about what your site is intend to do regarding redirects but what actually happens. If you redirect to http://example.com the browser will actually access http://example.com/. If you enter http://example.com in the URL bar the browser will also access http://example.com/. Same with https:// instead of http://. This is because there can be no empty absolute-path used as request-target in the URL. It will be at least /. See the standard and look at actual traffic. Jun 30 at 20:14
  • 2
    @rexkogitans We are not talking about any trailing slash. Yes, if the URL is http://example.com/thing and the server redirects to http://example.com/thing/, that's a redirect. But a browser or a command line tool just cannot request http://example.com with no path at all. That URL is not valid on the wire in HTTP, so it will be corrected by the browser to append the missing / before it's sent. There won't be any redirect by the server in this instance.
    – jcaron
    Jun 30 at 22:51
13

There is no "secure" redirection between http and https. The first step is insecure (http) and can be compromised with a relative ease.

Considering this, it is not really important from security viewpoint if the insecure steps are one or more.

What can be used to improve the situation:

  • HSTS : only the first request will be http. Subsequent requests will always go directly to https browser-side.
  • advertize the https link. Good if the users are not expected to type it in their browser, but follow a link instead.
3
  • Sorry to be more specific, but I meant to say the 3 redirection are auto redirections. So user landing on http://www.example.com is first seemingly auto redirected to http://www.example.com/, then to https://www.example.com/. It won't really post any security risk since user typing http link will be auto redirected, cheers! Jun 30 at 14:02
  • 3
    @NgSekLong since the first request is over HTTP, it is insecure, so it can be intercepted and send to an attacker's server, which won't redirect them. Jun 30 at 20:13
  • I see! That's make total sense. Yes we already implemented HSTS and advertised the https link as suggested. Jul 1 at 2:21
5

You should not be providing plain-text HTTP service at all, and then there's no redirect problem. Modern browsers will attempt an HTTPS connection anyway. E.g. if you enter example.com, the modern browser attempts https before http. Even if you attempt http://example.com, decent browsers (everything modern I think) will attempt https if the http connection was rejected (i.e. closed port).

Another important thing to remember: any internal links or references you provide from within your site should ideally be relative, but if they are absolute for any reason then they should be https-only - browsers routinely reject unsafe redirects to same domain from within secured content.

Corollary: On the firewall protecting your service, make sure that the rule for port http (80) is REJECT, not DROP. The latter would cause a connection time-out, and that will provide not only bad user experience, but also it's not common for browsers to retry with https after an http timeout. To prevent participation in reflected traffic DOS attacks, make sure that the outgoing rate for port 80 (and all other ports that REJECT connections rather than DROPping them) is limited per remote IP address. Typically you'd let Cloudflare or somesuch worry about that, though.

2
  • 1
    Oh wow, I was about to write a snarky comment about how this is BS, but I looked it up and it's true. Glad I learned something today.
    – MechMK1
    Jul 1 at 19:53
  • Thanks for the info, will investigate on the firewall REJECT option which seems very promising, cheers! Jul 2 at 0:56
3

It's no less secure than a direct http to https redirect. Technically an attacker may get two chances to intercept the redirect - but if someone is attacking your network, it is usually all or nothing. Either they intercept both redirects (just as bad as a intercepting one) or neither.

1
  • 1
    What we have here is what looks like a late duplicate of a previous answer but only this one says something about the actual threat model.
    – Joshua
    Jun 30 at 17:59
1

Nothing is secure.

Security is a direction, not a destination.

Sure it's good to get people to use https. So redirecting from http to https is more secure than keeping users in http without redirection.

But it's a whole lot better to use HSTS, and put your domain in the HSTS preload list: https://hstspreload.org/

You could go another step further still, and completely shut off your http (non-tls) server. (Gasp) How uncouth!

Or perhaps take it to the most secure option, and host only a simple message on http (non-tls) that instructs the user that you will never provide non-https content and to manually type https://yourdomain.com to get to the site and explains why redirects are bad.

That last step has the bonus of gradually changing user behavior to expect https and try that first.

It still won't be secure. But it will be more secure.

2
  • The 'simple message' should not match the style of your brand. There is value in it causing the user discomfort and pause. If you make the redirect easy you enable behavior that makes the attacker's job easier.
    – Billy C.
    Jul 2 at 6:32
  • Correct and valuable answer to the title question; other answers are myopic but otherwise good. Jul 2 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.