Non-secure requests are not automatically upgraded to HTTPS

How it was found

Non-secure requests to hackerone.com (e.g. http://hackerone.com) are not automatically upgraded to HTTPS. This is not something you would notice when you use the latest version of modern web browsers such as Google Chrome or Firefox, because hackerone.com is HSTS preloaded. When a domain is preloaded, non-secure requests for these domains are internally upgraded to HTTPS. However, there are still browsers that either haven't implemented HSTS preload lists, or don't have hackerone.com on their HSTS preload lists (yet).

Take for example Safari on iOS, which doesn't have hackerone.com in its HSTS preload list. When you open http://hackerone.com in Safari and head over to the 'Sign in' page you will see that the connection is not upgraded to HTTPS. Moreover, if you enter your username and password, and hit 'Sign in', the form is sent in the clear over a non-secure connection.

Since non-secure requests aren't upgraded to HTTPS, the user will never receive instructions (via the Strict-Transport-Security header) to set the HSTS "cookie" for 'hackerone.com. Which means a secure connection is not enforce until the first time the requests a resource over HTTPS, because that response will include the Strict-Transport-Security` header.

Steps to reproduce

cURL

1. Send a HEAD request to http://hackerone.com: curl -I http://hackerone.com.
2. You will see that the server does not instruct the client to upgrade the connection to HTTPS. The server responds with a 200 OK status code instead of 301 status code with the response header Location set to https://hackerone.com.

Firefox

1. Clear the Site Preferences: Click History --> Clear Recent History..., select Everything, tickSite Preferences, and hit Clear Now. This is to ensure Firefox forgets about an HSTS settings for hackerone.com.
2. Turn off the use of the HSTS preload list. Set network.stricttransportsecurity.preloadlistto false on the about:config page.
3. Open http://hackerone.com.
4. You will see that the non-secure connection is not upgraded to HTTPS.
5. Also note that when you click Sign in in the top-right corner, enter your email address and password, and hit the green Sign in button that your credentials are sent in the clear to the non-secure endpoint http://hackerone.com/sessions.

Exploitability and impact

Granted, it is kind of hard to exploit this vulnerability, because, first of all, it requires an attacker to be in a privileged network (he/she needs to be able to see what's going over the wire). Then the attacker would need to trick the victim into opening http://hackerone.com in a browser that doesn't have hackerone.com HSTS preloaded and which doesn't have any HSTS cookies for hackerone.com from a previous secure visit to hackerone.com. When all these conditions are met, an attacker could for example steal the victim's HackerOne credentials, or inject some malicious scripts into any page. This is possible because the connection is never upgraded, and the site allows forms such as the login form to be posted to a non-secure endpoint (see the screenshot attached to this report).

Mitigation

Non-secure connections need to be upgraded to HTTPS as soon as possible using a permanent redirect. But since the website allowed me to send my username and password in the clear over a non-secure connection, I was also thinking that you would probably want to prevent forms from being posted to non-secure origins. One possibility is to enforce the client to only send AJAX requests to secure origins using the Content Security Policy connect-src directive.