Missing transport security headers are commonly discovered during penetration testing of web applications. You might have encountered this issue in a report for your own application or heard about it as a vulnerability. But why is this an issue? This article attempts to explain why this specific header has shown up on your pentest report.
What is HSTS?
HSTS stands for HTTP Strict Transport Security. It takes the form of a header returned by your server in the following format.
| Strict-Transport-Security: max-age=<expire-time> |
This tells the browser that it should not load the site over an unencrypted HTTP connection. If a user attempts to do so, for instance by typing http:// in the URL bar manually, the browser will automatically switch the protocol to request the site over an encrypted HTTPS connection.
The max-age directive in the header tells the browser how long this rule should be followed. If your site returns this header with every request, then that time will be continually renewed, ensuring that your users never load the site over an unencrypted connection, accidentally or otherwise.
You can also optionally add a directive to include all your subdomains like so:
| Strict-Transport-Security: max-age=<expire-time>; includeSubDomains |
What if I Don’t Run My Site On HTTP?
Since industries have become more security conscious and it has become more common for sites to run over HTTPS by default, many organisations don’t even serve content over HTTP. If a user attempts to connect to their site over an unencrypted connection, they are automatically redirected to a safer, encrypted one.
This begs the question, if the site doesn’t even run on HTTP, why the need for an HSTS header? Surely the user can’t accidentally use what isn’t there. This, however, assumes that the user is getting the content of your site directly from your server without any tampering happening in the middle. This is not necessarily the case.
SSL Stripping
An attacker may manage to position themselves on the network between the user’s machine and your web server. This is known as a Man-In-The-Middle or MITM attack. They may achieve this my poisoning traffic on a network, or by luring unsuspecting victims to fake free Wi-Fi they have set up somewhere public, like a coffee shop.
If they can achieve this position, they can alter the information exchanged between the user and your website. Even if your redirects to encrypted connections, the attacker can simply alter the response sent from your site to remove that encryption. Then, when the user has loaded the unencrypted page, the attacker can see any sensitive information they put into the website over an unencrypted connection.
Figure 1 Flow of an SSL Strip Attack
HSTS can prevent this attack from being successful. If a user has previously visited your site and received the Strict-Transport-Security header in a response, then when the attacker returns an unencrypted HTTP page that appears to be from your site, the user’s browser will refuse to send future requests over the unencrypted connection. This prevents the attacker from being able to steal any sensitive information.
HSTS Preload List
HSTS goes a long way to prevent SSL Stripping, but there are still some issues with the model described so far. For it to work, a user must visit your site before they are subjected to the attack. If their browser has never seen the header before they fall victim to the attack, the attacker can simply remove your HSTS header before returning responses to the user.
This is where the HSTS Preload List comes in. Google maintains a list of domains that are pre-loaded as employing HSTS. Browsers which use this list, which includes most modern options, will use the HSTS feature for any domains on the list without first requiring that the user visits the site and receives the header.
You can see if you can add your domain to the list by visiting the HSTS Preload List Submission page. This is well worth investigating to improve the security posture of your sites.
Conclusion
HSTS is a feature that is available in all modern browsers and is incredibly easy to implement for development and IT teams. However, it is often found not to be in use when web apps are assessed. It is highly recommended that your organisation take this simple step to improve the security posture of your applications and protect your users’ data. For more information, see the links below.
HTTP Strict Transport Security (chromium.org)
