Web Security 101: Understanding Strict-Transport-Security Headers

In this series of evaluating web security headers, we are now diving in with HSTS, the HTTP Strict-Transport-Security response header.

I will usually explain this in a way my nephew always asks fundamental questions: starting with few why’s until we get to how the universe was created and then some. But in this article, we will stop after a few whys.

How do we set the header?

Typically, you should set a HSTS header something like:

Short explanation:

• ‘Max-age’ 63113851 (in seconds, means roughly two years). This informs the browser how much time to remember this header setting. Ideally, max age should be set to two years.
• ‘includeSubdomain’, a nice addition. Even if we should handle security headers in subdomains as well, it’s an important attribute just so the browser is already instructed about the HSTS settings in a web app, if previously someone accessed the root domain.
• ‘preload’ is an optional directive that can include the domain in browsers’ preloaded HSTS lists, which are hard-coded into the browser. Optional, but we considered it an important attribute, nevertheless.

Why preloading is necessary?

The strict settings are not enforced on the initial load if not. Initially, accessing a website via http(intentional, or if someone forced that connection with malicious intent), it might cause a non-https connection instead.

Why is this header important?

In short, it informs the browsers that the site should only be accessed using HTTPS, and any attempts at using non secure HTTP access are automatically converted.

HSTS Enabled server

Why?

HTTP request if is not secured, using HTTPS as a first layer, it means that the data transmitted over the request is sent of course un-encrypted, and plain text.

We will cover in a separate article, but while learning cybersecurity or just how the web works, we can easily see how un-encrypted communication can be visible while monitoring a network. And if we consider how the data is sent in a plain text, this means that anywhere the data is carried, from Internet service provider, various servers all over world, back and forth, accessing and using HTTP is one of the most unsecure thing we can do on the internet.

Can we somehow protect HTTP requests? Yes.

Using VPN. And this is again not a sponsored ad. As I like to ‘joke‘. A VPN is not something that fixes everything, but in terms of data handling, we must admit that it has a great use in adding a security layer over our daily routine in the device. Effectively if we use a VPN while accessing a HTTP, the VPN will automatically encrypt the data, so no plain text anymore, if we have someone listening over the network.

Going back to HSTS

Although a critical header nevertheless, Strict-Transport-Security does not mean that it cannot be bypassed. However when it does work, it prevents protocol downgrade attacks.

Protocol downgrade attack?

Man-In-The-Middle downgrade attack

In a downgrade attack, attackers can take advantage of network vulnerabilities, forcing encrypted HTTPS connections into unencrypted HTTP. This attack type is effective because HTTP data as previously stated is visible in plain text, revealing sensitive information like usernames, passwords, and other private details.

Strict-Transport-Security limitations

1. One limitation we already presented it, not using preload, attackers can still bypass and force http requests.

2. Browser support: while modern browsers widely support this header, older browsers or older versions of modern browsers may be susceptible. As we say in cybersecurity, we are as strong as the weakest link. So even if we enforce and improve security posture in many areas, the entire ‘software’ chain that ends with the actual user’s device and browsers needs to be taken into consideration.
3. Man-in-the-middle attacks. If the attacker has already compromised the network, they can easily intercept the initial connection before HSTS takes effect. They might prevent the header being sent altogether and force a protocol downgrade attack. We will dedicate a separate series to man-in-the-middle attack, because it’s also representing an area in the software chain that can be affected even if on our end we do everything possible to improve the security of our app.

Final remarks

The variety of browser engines, versions, and flavors makes it difficult to know how all headers and their attributes are enforced, even with header settings in place. The frequent nature of browser updates can lead to the removal of caching and modifications in functionalities, potentially impacting header implementation. Our general observation is that max-age time, and forcing or removing certain cache options, don’t always behave as expected.

Photo by Ilya Pavlov on Unsplash.