HTTP Security Headers

HTTP Security Headers

There is a number of HTTP response headers that you should use to increase the security of your web application. They are referred to as HTTP security headers.
Once implemented, HTTP security headers restrict modern browsers from running into easily preventable vulnerabilities. They also provide yet another, additional layer of security by helping to mitigate security vulnerabilities and prevent attacks (like XSS, Clickjacking, information leakage, etc.). But it is important to mention that HTTP security headers are not intended to replace proper, secure code.
In this lesson, we will explore the most important HTTP security headers to help you better understand their purpose and how to properly implement them.
Below, you can see a sample HTTP response where all the security-related headers are highlighted.

image

1. HTTP STRICT TRANSPORT SECURITY

HTTP Strict Transport Security (HSTS) is a mechanism that prevents user-agents (a browser or any kind of program designed for communication with a particular server) from browsing a website via an unencrypted connection in case an encrypted connection can be established, and only using a trusted certificate.
If the request is communicated through an unencrypted channel, it can be captured and tampered with by an attacker. The attacker then can steal or modify any information transmitted between the client and the server or redirect the user to a phishing website. So, the first goal of HSTS is to ensure traffic is encrypted, so it instructs the browser to always use HTTPS instead of HTTP.
Usually, browsers allow users to ignore TLS errors and continue browsing potentially insecure websites. With HSTS enabled, the user will be unable to skip the browser warning and continue. The second important goal of HSTS is to make sure that the traffic is encrypted using a trusted and valid certificate.
Below, you can see a screenshot with the error that the user gets when the certificate of the target website is no longer valid (note that the user is unable to proceed to the target website).

image

When HSTS response header signals the browser that the certain domain must be requested only using HTTPS, the browser saves this domain to the HSTS list and keeps it there for the timeframe specified in max-age directive of the Strict-Transport-Security header.
There are two cases when HSTS doesn’t provide proper protection:

  • when the user hasn’t browsed to the website before and is making his very first request to this website over HTTP,
  • when existing HSTS data has already expired.

To resolve this, it is possible to have a domain included in the HSTS preload list which arrives baked into most modern browsers.
(Note that enabling HSTS and adding a domain to the HSTS preload list must be tested beforehand. A mistake in HSTS and TLS configuration may lead to a denial of service.)
Below, you can see a screenshot of the webpage with HSTS settings for Google Chrome browser.

image

2. X-XSS-PROTECTION

Some modern browsers have built-in XSS protection mechanisms that can be used as an additional layer of security against Reflected XSS. The main problem with that is that all of the browsers implement built-in XSS filtering differently, so to add more control to the process and make sure that the loading of a page with the malicious content will be blocked, the X-XSS-Protection header is needed.
X-XSS-Protection header is an optional HTTP header that performs XSS filtering by defining the anti-XSS mechanism behavior: from sanitizing the page by blocking injected Javascript to preventing page rendering and reporting the violation.
By default, browsers that support XSS filtering have it enabled. Though it can be disabled, this is considered a bad practice; often, if an application requires XSS protection to be disabled in order to function properly, it is an indication that the application is quite likely vulnerable to XSS.
Please note that only using the X-XSS-Protection header will not protect your application from XSS, but this header will make an important input in your defense-in-depth strategy and make it more robust.
Below, you can see a screenshot of the Google Chrome webpage that was blocked by the built-in XSS filter.

image


3. X-FRAME-OPTIONS

X-Frame-Options header a defines if the webpage can be rendered inside an <iframe>, <frame>, <applet>, <embed> or <object> tags. Depending on the directive, this header either specifies the list of domains that can embed the webpage, or allows the page to be embedded only inside pages of the same origin, or totally prohibits embedding of a webpage.
The main purpose of the X-Frame-Options header is to protect against Clickjacking. Clickjacking is an attack when the vulnerable page is loaded in a frame inside the malicious page, and the users are tricked into interaction with buttons and other clickable UI elements (e.g. unknowingly clicking “likes” or downloading malicious files) of a vulnerable page without their knowledge.
(Note that setting X-Frame-Options with <meta> HTML tag inside a webpage doesn’t work. Use HTTP headers to set it.)
Below, you can see a screenshot of the webpage where the content of another page was denied to be displayed in a frame because the X-Frame-Options header disallowed the browser from doing so with a deny directive.

image

4. X-FRAME-OPTIONS AND CONTENT-SECURITY-POLICY

X-Frame-Options is also covered by Content-Security-Policy (CSP). CSP is a suite of headers with security directives for multiple uses (which will be covered in their own lesson). Among these security directives is the frame-ancestorsdirective which pursues the same goal as the X-Frame-Options header. The main difference between them is the implementation of the SAMEORIGIN directive of the X-Frame-Options header.
Various user-agents interpret SAMEORIGIN directive in a different way, and some of them only check the top-level domain. Whereas with the CSP’s frame-ancestors directive, the whole chain of origins is checked. (The example of the chain of origins is an iframe inside an iframe, inside an iframe, and so on.)
The CSP W3C recommendation states that with the CSP frame-ancestors directive being introduced, the X-Frame-Options header becomes obsolete. Thus CSP should be used to prevent Clickjacking in the first place and the X-Frame-Options header should be used for backward compatibility with browsers that don’t support this CSP directive.
Below, you can see a screenshot of the webpage where the content was denied to be displayed due to Content Security Policy restrictions.

imageReference: codebashing.com


Comments are closed.