In this article, we will explore the use and implementation of the most important HTTP security headers.
In regard to Spectre and Meltdown, the correct use of HTTP headers is more important than ever – even Google developer Surma published a guideline for web developers to secure users through the use of security headers.
After all, Spectre and Meltdown are not the only attack scenarios that can be prevented by setting the right HTTP security header.
What are HTTP Security Headers?
The HyperText Transfer Protocol (HTTP), more especially HTTP response headers, transfer bits of information once a website is requested (through a browser) from a web server. The information that is sent contains status error codes, content-encoding, meta data, cache rules and more.
A set of security headers was and is developed by the Open Web Application Security Project (OWASP) to instruct browsers how to behave when handling your site´s data and content.
This is a necessary and reasonable action to prevent safety issues. Read on to learn more about the different exploits and how you can secure your site against these exploits.
Clickjacking, also known as user-interface (UI) redress or UI redressing, is a technique, where attackers use transparent or opaque layers to provoke unintended clicks on a manipulated interactive element.
For example, a user clicks on the “Send” button at the end of a contact form which does not send the contact information but starts to run malicious code in the browser. The attack can range from unintended social media sharing up to giving access to the user’s microphone and camera by changing browser plugin settings.
Preventing Clickjacking requires the right set of the X-Frame-Options HTTP-Header. Using DENY prevents any domain from framing the content, including your own.
With SAMEORIGIN you allow displaying the resources on your own domain, whereas ALLOW:FROM followed by a domain, allows the display of content on the specified domain.
Downloading (and executing) unwanted software from a website is called “drive-by downloads”. Attackers hide an executable file in e.g style.css. To assess the content type of the file, the browser assesses the content of the resource. If an executable file is detected it automatically starts downloading and executing. This can open a backdoor for any future attack, where attackers can execute any code on the infected system, even without using the browser.
Not only HTTP browser communications are open to this security flaw but WebSockets, which provide a similar but different way of communicating data, as well!
To secure users from drive-by downloads, set the X-Content-Type-Options HTTP header to nosniff. This should be done for any resource.
Setting the option prevents the browser from identifying the content type and downloading respectively executing malicious code.
The importance of this security header has to be emphasized since the Chromium developers argued that nosniff is one of the must-have tasks to secure users from Meltdown and Spectre.
Cross-Site-Scripting (XSS) Attacks
XSS attacks use vulnerabilities in applications to insert malicious code into a website. This code is executed by the browser. For example, an attacker can use an input field of an insecure website to insert code, which is then directly being rendered on the website, once the form is submitted.
To impede XSS attacks the use of the X-XSS-Protection header is recommended. The technology behind this security header triggers the browser internal XXS heuristics.
These heuristics vary widely from browser to browser: Chrome has this option as a default setting whereas the internal XSS auditor in Safari needs to be activated by setting the header. Firefox, however, does not provide any heuristics, with or without setting the header.
Another important security measure against XSS attacks is the use of Content-Security-Policy (CSP) header. The functionality of this header is to define which sources are valid for each resource. Since the CSP header can influence inline scripts, it is recommended to use the reporting option first (Content-Security-Policy-Report-Only). With the help of the report, a more gradient selection of rules can be obtained.
Web servers and browsers can reveal information about your systems over HTTP headers. This can be exploited by checking the model and version of your web server to attack a specific vulnerability.
On the other hand, browsers often disclose a lot of information via the Referrer header, which is used by attackers as well.
Preventing Information Disclosure can be achieved by using the Referrer-Policy header. The header regulates to which targets the referrer information is transmitted and how much information is passed on.
By setting the header to no-referrer, no information is transferred at all. Using no-referrer-when-downgrade sends generally all information, except the target site is less secure. An example is a communication from HTTPS to HTTP.
The Referrer-Policy header offers a lot of options which are well documented and publicly available on Scott Helme’s website.
Security Header in wao.io
As you have read there are many security headers and a lot of different options to use them. Setting the headers right requires consistent use of the different headers across every site of your website.
To minify the manual work and support the security around the web, wao.io offers the possibility to toggle security headers with a simple click.
Websites that are placed in the hall of shame by securityheaders.io, a security header analyzer, can upgrade their score to an “A” result by using wao.io. It works out-of-the-box without any manual code changes. Secure your website in 3 clicks – signup, add website and toggle security header.
Sign up for free to secure your website now!
If you are even more interested in the topic of security and browsers, we cordially invite you to meet us at the next WebPerf Meetup in Cologne, Germany. At the 1st of February our lead developer, Sebastian is giving a detailed report on the topic and its relation to the security flaws of Spectre and Meltdown.
This article was originally written & published by Verena W. and translated by Heinrich R.