2. Frond End Security Basics: HTTP Strict-Transport-Security (HSTS)

2. Frond End Security Basics: HTTP Strict-Transport-Security (HSTS)


Properly implemented data protection for a web application allows the users to know who they are communicating with, whether or not their communication channel is encrypted, and that the data is not manipulated in transit. This is usually achieved by using HTTPS protocol for communication between the user and the web application.
But sometimes applications accept connections through HTTP first, upgrade to HTTPS and redirect the user to HTTPS version of the application. Thus the application first allows the user to communicate via unencrypted connection before the redirect. And when HTTP protocol is used, the traffic is sent in plain text, therefore creating an opportunity for the attacker to see and modify the traffic, performing a Man-in-the-Middle attack.


Let’s consider an example where the attacker can take advantage of the fact that the site is available over both HTTPS and HTTP and redirect the visitor to a malicious website instead of the secure version of the original site.



Bob is an attacker. He opens up a malicious hotspot at a food court of a big shopping center and bridges it to some internet connection. Visitors looking for free WiFi see Bob’s hotspot, connect to it, and begin browsing the web while Bob reads all the unencrypted traffic conducting the Man-in-the-Middle attack.
Bob knows that an extremely popular online marketplace Bozone.net accepts HTTP requests before redirecting users to HTTPS. At the same time, Bob suggests that visitors of the shopping mall would like to compare prices and would visit Bozone.net for that purpose. So he created a phishing page asking the Bozone.net user to enter their website credentials.
Now Bob is analyzing the traffic that is going through his hotspot with a Proxy tool, looking for HTTP requests to Bozone.net which he can intercept.



Alice is a legitimate user of the Bozone.net website. She has just found an interesting book in a book store and now she wonders if she could buy this book at a better price at Bozone.net. After finding a free hotspot at the food court, she opens the browser, types bozone.net and hits Enter.



In his proxy tool, Bob sees that someone has just requested Bozone.net website over HTTP. He intercepts server response and sends a redirect to his phishing page at Bobzone.net in response.


Help Bob create a malicious payload. Click ADD to change the original server response to malicious response into the Proxy window.
HTTP/1.1 301 Moved Permanently
Date: Thu, 10 May 2018 09:14:11 GMT
Content-Length: 0
Connection: close
Location: http://bobzone.net

Source, Destination, Protocol, Info, 208.97.315.10, TLS, Application data

208.97.315.10,, TLS, Application data, 208.97.315.10, TLS, Application data

208.97.315.10,, TLS, Application data, 208.97.315.10, DNS, bozone.net, 208.97.315.10, HTTP, GET / HTTP/1.1 Response from http://bozone.net:80/ HTTP/1.1 301 Moved Permanently Date: Thu, 10 May 2018 09:13:24 GMT Content-Type: text/html; charset=UTF-8 Server: Apache Content-Length: 0 Connection: close Location: https://bozone.net <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" prefix="og: http://ogp.me/ns#"><head profile="http://gmpg.org/xfn/11"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> .......



After Alice’s browser receives this malicious redirect response, it tries to connect to the server provided and sends the HTTP request to http://bobzone.net. Bob’s phishing page opens.
As Alice is busy searching for a book, she doesn’t pay attention to minor changes in the URL. She enters her credentials and gets redirected to the Bozone.net website.
Enter the following credentials to sign in as Alice:
Email: [email protected]
Password: 12345!



Alice is redirected to the Bozone.net page.
Now look at the server log of Bob’s server: there is a string with Alice’s credentials.


This attack was made possible because HTTP is a default protocol for all requests where users don’t explicitly specify HTTPS. So, when Alice types bozone.net, it is interpreted by the browser as http://bozone.net, unless Alice explicitly specifies that HTTPS must be used. As this website relies only on 301 redirects for switching from HTTP to HTTPS, Bob was able to capture Alice’s network traffic over HTTP.


To mitigate the vulnerability, consider setting HTTP Strict Transport Security (HSTS) policy that prevents user’s browser from accessing the website via unsecure connection and thus from being manipulated by some malicious party.
The HTTP Strict Transport Security header informs the browser that it should automatically convert all attempts to access the site using HTTP to HTTPS requests instead. This ensures that the entire communication channel is encrypted before any data is sent, making it impossible for attackers to read or modify the data in transit.
HSTS policy has several directives:

  • max-age directive sets a time frame in seconds during which the browser will automatically upgrade HTTP requests to HTTPS.
  • includeSubDomains directive spreads HSTS policy to all subdomains of the website.
  • preload directive notifies the browser that the site is in the HSTS preload list

The HSTS header looks like the following:
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload



Once a browser that supports HSTS receives the Strict-Transport-Security header returned in HTTPS response (if it will be returned over HTTP, the browser will ignore it), it will only issue subsequent requests to that site over the HTTPS protocol.
If the user has never browsed to a website before, then the HSTS header was not set yet, implying they would still be vulnerable, but only for the first time they ever browse to the website. To resolve this, it is also possible to have a domain included in the HSTS preload list, which arrives baked into a browser. Having the website preloaded into browsers mitigates the issue with the first browsing being vulnerable to Man-In-The-Middle attack. For further information about preloading check https://hstspreload.org/.
HSTS can prevent Man-in-the-Middle attacks. If Bob attempts to perform an SSL stripping attack, then by providing Alice with an HTTPS connection to bozone.net he would have to issue an untrusted certificate due to HTTPS requiring valid signatures from a certificate authority. If Alice browses to an untrusted certificate, without HSTS she would be prompted to accept the invalid certificate. But with HSTS, she will no longer be allowed to suppress the error without fundamentally changing the browser’s security settings.


Comments are closed.