Add another layer of website security by implementing HSTS
You’ve probably been hearing HTTP and HTTPS being discussed a lot in relation to website security. Google has been encouraging website owners to convert their sites from HTTP to HTTPS to improve security for site owners and visitors. This effort has been escalating to the point where Google’s Chrome browser now shows a “not secure” message near the address bar to notify users when they are visiting a site that does not use HTTPS.
This has had the positive effect of causing more site owners to make the switch. Yes, it comes with a cost and requires some effort, but it’s the right thing to do.
Why is HTTPS alone not enough?
The “S” in HTTPS stands for secure, which means that the communications between your web browser and the website you are visiting is encrypted, making the information much harder to read. This helps protect customer information, credit card numbers and helps improve the trust relationship between visitors and your organization.
Like all other security solutions, HTTPS strives to address specific threats and it’s very good at it; however, it is not designed to address all threats. In contrast, websites configured with HTTP Strict Transport Security (HSTS) notify the browser to enable HSTS and to remember this for a period specified in the HTTPS header. Once the browser knows HSTS is enabled, it will always use an HTTPS connection even when an HTTP (non-secure) link is clicked or when the domain name is typed into the address bar without a protocol. A browser that is aware that a specific domain is HSTS enabled will prevent the visitor from clicking through warnings about invalid SSL certificates.
Additionally, HTTPS does not protect completely against Man-in-the-Middle (MITM) attacks. In other words, using HTTPS does not prevent site visitors from adding exception rules in their browsers, which might allow a site visitor to downgrade your HTTPS connection to HTTP. Doing so would allow for non-encrypted communications, opening up your website visitors to vulnerabilities. However, HSTS prevents site visitors from adding this type of exception rule.
Adding Another Layer of Protection with HSTS
HTTP Strict Transport Security (HSTS) eliminates the practice of redirecting visitors from HTTP to HTTPS by requiring that the connection to the website happen only via . HSTS provides another layer of protection by targeting three specific threat classifications including:
- Passive network attackers – Over a local wireless connection, a nearby attacker can possibly eavesdrop on the user’s HTTP connection. By stealing unsecured cookies, the attacker can gain authentication credentials.
- Active network attackers – An attacker can impersonate a user’s DNS server or spoof network from or offer a similarly-named “evil twin” access point.
- Imperfect web developers – Bugs or mistakes in code can create unsecure connections through style sheets and SWF (a.k.a. Flash) movies by having HTTP URLs embedded. This “mixed content” scenario can allow attackers to use a script to inject a login page into an insecure page and compromise the entire login process.
Having a high degree of focus on the three specific threats mentioned above also means that there are some threat classes that are not addressed. HSTS does not protect against:
- Phishing – Phishing attacks happen by a variety of methods with email being a common approach. Phishing emails are ones that look legitimate, but include links to the attacker’s site to drive more traffic there or to trick the email recipient into giving up their credentials. Since these attacks happen outside of an HSTS-protected site, there is no way for HSTS to protect the communications.
- Malware – Malicious code running on a user’s computer can compromise a browser session even if HSTS is enabled on your website since it could inject code between the switch from HTTP and HTTPS. The user’s computer is out of the control of HSTS, so protecting the communications could be bypassed.
More About How a Browser Knows HSTS is Enabled
Web servers return headers when a web page is visited, which provides a variety of information including information about the server. HSTS-enabled websites return a header very similar to:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Let’s break down the different parts of the HSTS header and explain why they are necessary.
- Strict-Transport-Security notifies the browser that HSTS is enabled. Without this, the browser won’t know the website relies on HSTS.
- max-age=31536000 specifies that the browser should remember that HSTS is enabled for the visited domain for one year since there are approximately 31,513,600 seconds in a year. After a year, the browser will forget that HSTS is enabled until it visits the site again. HINT: There’s a security concern at this point since a hacker could intercept the communications on the visitors first request to the site after the max-age expiration if the HSTS preload option is not set.
- includeSubDomains tells the browser to include all subdomains associated with the parent domain. Specifying that all subdomains should be included eliminates the need to provide separate HSTS headers for every subdomain. This reduces the number of possible failure points since there is only one place to manage HSTS headers.
- preload tells the browser that the site owner consents to having the domain preloaded by the browser. Google developed the “HSTS preload list” feature and it is supported by Chrome, Firefox, Safari, Opera and Edge browsers. Preloaded domains get built into the browsers, which prevents the security issue mentioned in the “max-age” section above. During a browser’s first visit to a website, it does not know whether HSTS is enabled, meaning that the user is unprotected until after his/her first HTTPS connection to the domain. The “HSTS preload list” prevents this problem by notifying the browser before it tries to connect to the web server.
Implementation
When someone visits a web page, the web server sends an HTTP header as part of the two-way communications between the browser and web server. When you enable HSTS support for your website, the web server notifies the visiting browser of this fact by including it in the headers. For WordPress websites, adding the HSTS header can easily be implemented via plugins such as Security Headers or HTTP Headers. Be sure to reference the previous section for information about which options to select and what values to enter.
Make the Web A Better Place
Trust is a very important aspect of running a successful business and every step you take to improve security will help improve trust. The more people that work to improve web security the harder hackers will have to work. Similar to a tug of war, you want more strong people on your side. It’s a simple process to implement HSTS on your website that shows you care about your employees and customers, and it can be done in under 15 minutes.
