Extra Hardening: Take care your HTTP Security Headers

Posted on May 15, 2017 at 2:45 am

No Comments

There are millions of websites around the globe that are publicly available. Due to this public availability of websites they have become an active targets for hackers. Hence website owners are constantly trying to understand the threat landscape and develop solutions for threats mitigation.
HTTP Security Headers provide mitigation solutions of various threats including cross site scripting, click jacking, code injection and drive by downloads attacks etc.
This article will describe the most used HTTP security headers, their methodology of threat mitigation and their configuration guides for Apache and NGINX web-servers.

List of HTTP Security Headers that are covered in this article:

  • Content Security Policy (CSP)
  • X-XSS-Protection
  • X Frame Options
  • X Content Type Options
  • HTTP Public Key Pins (HPKP)
  • HTTP Strict Transport Security (HSTS)

Content Security Policy (CSP)

Overview
The web browsers trust all the contents of a website including its web pages, style sheets, fonts and java script files etc. Due to this trust relationship the browsers loads and executes all the content of a website without any content authentication. This browser behavior can be exploited by hackers in running malicious codes on the target web browser. Content security policy is a solution to this problem as it defines approved contents for websites. CSP instructs browsers to load and execute approved contents of a website only and subsequently helps in preventing various attacks including cross site scripting and code injection attacks. If a website has cross site scripting vulnerabilities then it is possible to upload a malicious code on the vulnerable website and subsequently the code gets executed on client’s browser while visiting the website.

Benefits
It prevents websites against cross site scripting and code injection attacks.

Apache Configuration
Add the following lines in httpd.config file and restart the browser:

Header add Content-Security-Policy "default-src 'self'"

Nginx Configuration
Add the following in server block in nginx.conf file:

add_header Content-Security-Policy "default-src 'self';";

X-XSS Protection

Overview
Some browsers provide filters for the protection against cross site scripting attacks. These filters are enabled when a server returns a HTTP header containing X-XSS protection header. Hence it can be concluded that X-XSS protection header is used for the protection of cross site scripting attacks. However it should be noted that if content security policy is enabled on a webserver then there is no need to enable this header, as CSP will provide protection against cross site scripting attacks. Currently Internet Explorer 8+, Chrome, and Safari support this feature.

X-XSS protection header can be customized with the following settings:

  • x-xss-protection:0;(disable XSS filter).
  • x-xss-protection:1; (enable XSS filter, after XSS detection the browser will sanitize the page).
  • x-xss-protection:1; mode=block (enable XSS filter, after XSS detection the browser will render the page instead of sanitization).

Benefits
Prevents cross site scripting attacks.

Configuration for Apache

header always set x-xss-protection "1; mode=block"

Configuration for Nginx

add_header x-xss-protection "1; mode=block" always;

X Frame Options

Overview
This header tells web browsers how to behave while handling website contents. X Frame Options header has been designed for the prime purpose of protection against click-jacking attacks. It directs the browser accordingly whether the page should be opened in a frame or an iframe. Currently it is supported by IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+.

There are three settings for X-Frame-Options:

  • SAMEORIGIN: This setting will allow a page to be displayed in frame on the same origin as the page itself.
  • DENY: This setting will prevent a page displaying in a frame or an iframe.
  • ALLOW-FROM uri: This setting will allow page to be displayed only on the specified origin.

Benefits
Provides protection against click jacking attacks.

Configuration for Apache

header always set x-frame-options "SAMEORIGIN"

Configuration for Nginx

add_header x-frame-options "SAMEORIGIN" always;

X-Content-Type Options

Overview
Some browsers have MIME sniffing features by default which helps browsers in identifying the requested content if the extension of requested file is different as documented in the content type header. Hackers try to exploit this feature for conducting cross site scripting attacks on webservers. Hence it is recommended that content sniffing should be disabled in web browsers. The content sniffing can be disabled by setting x-content-type security header to no-sniff in webserver configurations.
The issue with this security header is that it is not supported by all possible web browsers. The websites are accessed by users with all possible web browsers, hence the websites will not be fully protected against MIME confusion attacks even when x-content-type options header is enabled.

Benefits
It reduces the danger of drive by downloads, cross site scripting and MIME confusion attacks.

Example
Consider the case when a browser requests a HTML file from the webserver. The webserver returns a response header with the content type field set to txt. Now If MIME sniffing is not be disabled then the browser will identify that the requested file as an HTML one and display it as a web page, although it was declared as a txt file in content type header. If content sniffing is disabled then the browser will discard the response as the file extension of requested content is different from the extension documented in content type header.

Configuration for Apache
This header can be enabled by modifying apache settings or .htaccess file, by adding the following piece of code.

<IfModule mod_headers.c>
Header set X-Content-Type-Options nosniff
</IfModule>

Configuration for Nginx

add_header X-Content-Type-Options "nosniff" always;

Configuration for WordPress
Use the Security Header Plugin in order to implement this feature.

HTTP Public Key Pins (HPKP)

Overview
HPKP is a security policy enforced by web browsers like CSP and HSTS. It instructs web browsers which public keys should be accepted from the web server in the future. If the certificate authority gets compromised and attacker exploit certificates then with the help of the already communicated HPKP policy the browser will be able to identify the fake web server.

Working
When a client accesses a web server for the first time then the server send its public keys to the browser and subsequently the keys are stored by the browser. Now if the client tries to establish a session with a fake server (using fake public keys) then the browser will identify this server as a fake and subsequently notify the user about it.

Benefits
Protection against websites with fraudulent certificates. The users of a website having public key pins features enabled are less prone to man in the middle attacks.

Configuration for Apache
Add the following lines in the web server’s configuration file.

Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"

Configuration for Nginx
Add the following lines in the web server’s configuration file.

add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains' always;

HTTP Strict Transport Layer Security (HSTS)

Overview
Millions of websites around the web use the HTTPS protocol for securing the exchange of a user’s data. If the website session can somehow be downgraded from HTTPS to HTTP protocol then confidentiality of data can be compromised. This headache for websites can be nullified by a fix named HSTS. Technically HSTS is just a field in HTTP header that can be easily configured in any webserver. After configuring HSTS in a webserver the HTTPS websites cannot be downgraded to HTTP either by a legitimate user or an attacker.

Benefits
HTTP sessions cannot be downgraded to an HTTP session either by a legitimate user or an attacker. Subsequently eavesdropping of data will not be possible. Cookie hijacking will not be possible, as it will always be exchanged over HTTPS.

How HSTS Work
When a browser requests a HTTPS website with HSTS configured, the website returns a response header containing HSTS field. The browser upon seeing HSTS field remembers that this website should always be browsed using the HTTPS protocol. Now lets consider the case where a user browses a HTTPS website like this http://www.example.com, if HSTS would is enabled the browser will automatically be redirected to https://www.example.com
It should be noted that HSTS is identified with the field name "Strict-Transport-Security" in HTTP response headers of websites.

Examples of HSTS
For understanding HSTS we will take an example of Facebook website. HSTS is enabled on Facebook website that can be validated by seeing the response header sent as shown below:

Now it has been validated that HSTS is enabled on Facebook website, so we will try to open Facebook using HTTP protocol. The following figure shows that browser has automatically redirected the website to https://www.facebook.com

From the response headers shown above one can conclude that HSTS is enabled on Facebook web server.
Configuration for Apache
Edit your apache configuration file and add the following to your VirtualHost:

LoadModule headers_module modules/mod_headers.so
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"

Apache configuration files are website.conf (/etc/apache2/sites-enabled/website.conf) and httpd.conf (/etc/apache2/httpd.conf).

Configuration for Nginx
Add the following in server block for HTTPS configuration:

dd_header Strict-Transport-Security "max-age=63072000; includeSubdomains; ";

Conclusion

HTTP Security Headers are somewhat easy to apply while at the same time offer a great help in terms of securing your WordPress site to attacks. If you don't have access to your server configuration files we urge you to ask your hosting provider support to enable HTTP Security Headers for your site(s).

Leave a Reply

Your email address will not be published. Required fields are marked *