Security Headers

Security Headers

19. November 2018 Expert Topics

1 Comment // Reading Time: 6 min.

Measures to increase client security

All of the following measures protect visitors of your website from attacks by altered resources embedded on the site or man-in-the-middle attacks.
The headers can be set in the web server configuration, htaccess for apache for example, and need to be adjusted for the specific needs of your website.
These adjustments luckily limit to special external resources and features.

Content Security Policy Header

The CSP header can instruct the client browser to accept scripts, images and other embedded resources only from specified, trusted sources.
This means that all external sources present in the CSP header will be allowed to be downloaded and executed on your website, but all scripts and images from other sources, that are probably dangerous and therefore not trusted, will be ignored.
This makes attacks on the users - for example via XSS, manipulated images or hidden iFrames - considerably more difficult.

For example:

Header always set Content-Security-Policy "default-src 'self';"

This line will block everything that is embedded via script, link, img, iframe or object embed that does not come from the very same domain - including subdomain - the user is already on.

Since lots of websites use external resources from CDNs over stock images, this is not really a viable way to secure the website. Luckily we can fine grain the header to allow certain external services for certain resource types like so:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://*.googleapis.com; font-src 'self' https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com; img-src 'self'; frame-src 'self' https://www.youtube.com https://www.youtube-nocookie.com"

Now this header makes more sense, because it allows for certain external services to provide resources to the site.

script-src 'self' https://*.googleapis.com;

This script-src directive for example allows for scripts from our own domain ('self') and from every googleapis.com subdomain via HTTPS to be loaded.

https://developers.google.com/web/fundamentals/security/csp/

Feature Policy Header

The Feature Policy Header is preventing external scripts from accessing devices and resources of the visitors browser. In most cases there is no need to give an external script access to the users camera or microphone for example, hence this policy can be configured in a way to prevent access to these features. If in case a hacker succeeds in injecting bad code onto one of the external resources, it can not be exploited to hijack a visitors sensors or input devices to gather personal information and eavesdropping on him.

For disabling all hardware input devices such as the camera or speakers do:

Header always set Feature-Policy "geolocation 'none'; midi 'none'; camera 'none'; usb 'none'; magnetometer 'none'; accelerometer 'none'; vr 'none'; speaker 'none'; ambient-light-sensor 'none'; gyroscope 'none'; microphone 'none'"

This way there is no possibility for scripts to use any of the mentioned devices. If one of our own scripts needs to access one of the devices or features, we can allow this by setting the needed policy to 'self'. If we need to allow an external script to use one of the devices or features, we can explicitly allow it by entering the domain name of that script into the policy like geolocation maps.google.com.

https://developers.google.com/web/updates/2018/06/feature-policy

X-Frame Options - Header

The X-Frame Options header is configured to prevent the website from being embedded as an iFrame on other pages that are not authorized to do so. This is aiming at phishing attacks in which the original website will be embedded into a manipulated phishing site to make the visitor think that everything is fine, but entered data like usernames and passwords will actually be sent to the attackers own server.

For allowing the website to embed itself into an iframe (for lightboxes for example):

Header always set X-Frame-Options "SAMEORIGIN"

You can allow a certain domain to display the website in an iframe by adding:

 

Header always set X-Frame-Options "allow-from https://example.com/"

XSS protection - Header

The XSS-Protection Header is a way to activate the browser's own XSS filtering. Browsers such as Google Chrome or Internet Explorer have internal mechanisms that can detect XSS attacks and then prevent a web page from loading.

Header always set X-Xss-Protection "1; mode=block"

In the future, browsers may also provide a report about the incident to a given URL.

Header always set X-Xss-Protection "1; report=www.example.com/incident-reports"

Referrer policy - Header

The referrer policy header determines whether and under which circumstances the browser forwards the currently visited website to subsequently visited websites. It can be configured to send only the domain to visited non SSL protected sub pages of the same domain and hide the referrer in case the user is navigating away from the website entirely. Restricting the referrer protects the visitor from passing on data about visited sites to potentially untrustworthy websites.

Header always set Referrer-Policy "strict-origin"

X-Content Type Options - Header

The X-Content-Type-Options header has only one valid value: "no-sniff". The header instructs the browser to not guess the type of downloaded files in script or style tags. This can prevent attacks on the client, that use a fake MIME-type to trick the browser into loading a file as executable, even though it should not be. If the browser encounteres a file with a different MIME-type, it is going to ignore the file.

Header always set X-Content-Type-Options "nosniff"

Script Integrity

The server can calculate an integrity hash for its resources. It takes the contents of a script and calculates a hash that will be submitted alongside the embeded code and gives a visitors browser the possibility to check, if the contents of this script matches the provided hash and thus has not been changed on the way to them. This limits the possibility for an attacker to hijack a resource in a man-in-the-middle attack, because if the hash mismatches the script content, the visitors' browser will reject the script and not execute it.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

How to test the Security Headers

There is a test tool for the security headers out there: https://securityheaders.com

You can enter the domain to be tested into the input field and hit the Scan button to test it.

In the following report, there will be information listed about your servers response to the testers request. It lists the Security Headers that have been set and rates the websites' security with grades from A+ for best, to F for worst.

If your grade is capped at A, then there are warnings that stop your website from getting a better grade. These warnings could contain a used 'unsafe-inline' directive in the Content-Security-Policy.

The tool also presents you with additional information on every tested header as well as informing about upcoming headers, that will be relevant for security of web requests.

 

Our own software

We at sgalinski Internet Services have taken steps to make our internal tools as safe as possible. This is why we implemented a basic Security Header Policy into our own website-base, providing an A grade out of the box.


1 Comment

  • Peter

    Peter

    3 weeks ago

    Danke für den ausführlichen Artikel! Eine Frage zur CSP: werden die Prefixe "X-Content-Security-Policy" und "X-WebKit-CSP" aktuell nicht mehr gebraucht weil auch Firefox und Safari mittlerweile [...] Danke für den ausführlichen Artikel! Eine Frage zur CSP: werden die Prefixe "X-Content-Security-Policy" und "X-WebKit-CSP" aktuell nicht mehr gebraucht weil auch Firefox und Safari mittlerweile "Content-Security-Policy" verstehen?

    Drop files here
Drop files here