Application Security 101 – HTTP headers

This article is the first in a series that will discuss some of the most common issues with HTTP headers, which are often relatively easy to implement and can have a significant impact on the overall security posture of your application. We’ve previously talked about the proactive and reactive styles of application development and security testing.

In this article, we discuss HTTP headers which are a common misconfiguration. With recent changes to some frequently used headers, we’re going to cover what each header is, does and how it offers you protection when using a web application.

Let’s take a look at each of the currently recommended security headers, their purpose and how to configure them as per security best practices. At the end of this blog, we’ll look at how popular web servers can be configured to include or modify HTTP response headers.

1. Strict-Transport-Security

The HTTP Strict Transport Security (HSTS) header forces browsers and other agents to interact with web servers over the encrypted HTTPS protocol, which secures users from Man in the Middle (MitM) attacks by protecting against protocol downgrade attacks. This header has been specified in RFC-6797.

You should ensure that your site is accessible over HTTPS before this header is implemented.

An example configuration of the HSTS header is shown below.

 

 

2. X-Frame-Options

The X-Frame-Options HTTP header is used to define whether an application can be loaded in an iFrame within a third-party application. HTML iFrames are often used by malicious actors to create a fraudulent website, which mimics a legitimate application in an attempt to harvest user credentials. This is known as a “clickjacking” attack. This header is specified in RFC-7034

X-Frame-Options is easily implemented to deny a third-party application from loading your web application within iFrames. This can be achieved with the Content-Security-Policy (CSP) header, which we will discuss later. When this CSP directive has been implemented, the X-Frame-Options header becomes obsolete.

Deny ensures no rendering within a frame.

 

 

3. X-Content-Type-Options

The X-Content-Type-Options header was introduced to mitigate the threat of MIME sniffing attacks, preventing the browser from interpreting files as a different MIME type than what is specified in the Content-Type HTTP header. This can be used to inject client-side code into a user’s browser to steal sensitive information such as session cookies. You can read more about mitigating MIME attacks in this insightful article from Mozilla.

 

You can easily configure this header by setting the ‘nosniff’ directive, as demonstrated below.

 

4. Content-Security-Policy

The Content-Security-Policy (CSP) is a security standard that is used to mitigate XSS and clickjacking attacks and offers additional protections. It achieves this by allowing application developers to define where external resources (such as client-side JavaScript files) can be loaded from.

The CSP header is possibly the most difficult to configure correctly to achieve best security practice and maintain functionality. There are many directives that can be set, which without knowing their purpose, can lead to bypassing of intended protections if incorrectly configured.

There is a varying degree of support for each directive across browsers which adds to the complexity. Additional information on the CSP header and compatibility can be found on the Mozilla developer website. Configuring a secure but usable CSP can take some fine-tuning and will often take some experimenting to ensure security whilst maintaining the site’s desired functionality.

With that in mind, we will discuss the most commonly found misconfigured directive, the script-src directive. The script-src directive allows administrators to specify valid sources for JavaScript.

Take a look at the following examples.

 

This CSP on its own will only allow scripts to be loaded from the origin in which the document is served. This allows the browser to load JavaScript files from the same origin, where they have been included inside the web page. For example, where they have been specified in HTMLtag;

This is fine until you reach inline script tags; JavaScript that is loaded directly in the tag of an HTML document.

With the CSP header configured as above, this script won’t be executed as it’s in violation of the header configuration.

This is where the configuration of the CSP header can become complex, which can open a user to attack. Consider the next example.

 

Here we’ve added two additional sources, ‘unsafe-inline’ ‘unsafe-eval’, which allows the use of inline resources, such as inline script elements, javascript: URLs, inline event handlers, inline style elements, the use of eval(), and similar methods for creating code from strings respectively.

Now, our alert script from before will execute the below, as this no longer violates the CSP.

These sources are often implemented to loosen the restrictiveness of the CSP where there may be a considerable number of web pages that rely on inline scripts, event handlers and style elements. However, this allows malicious actors to perform Cross-Site Scripting (XSS) attacks. (Please note that we will discuss the (now deprecated) X-XSS-Protection header further down).

Can inline scripts be used safely with the CSP header?

Yes, there are two ways that the CSP can be configured to allow inline scripts. The first is to use a base64 encoded nonce value, the second is to use a SHA hash. CSP supports the use of SHA256/384 and 512 hashes. Examples of how to set this up can be found here.

As already mentioned, this is just a small example of the most common misconfiguration we see within the CSP header. However, with time, the CSP should be configured appropriately so that it provides maximum security benefits as well as maintains site functionality.

What about X-Frame-Options?

As touched on in the X-Frames-Options section, the CSP can also be configured to block the loading of sites within iFrames. This can be achieved by setting the following ‘frame-ancestors’ parameter, where ‘domain.com’ refers to external domains that are permitted to load the site within frames. Additional domains can be added in the same manner.

 

5. X-Permitted-Cross-Domain-Policies

This header is used to limit which data external resources, such as Adobe Flash and PDF documents, can access on the domain. Failure to set the X-Permitted- Cross-Domain-Policies header to “none” value allows other domains to embed the application’s data in their content.

If there is no requirement to load application data within web clients such as Adobe Flash Player or Adobe Acrobat (not limited to these), then the header should be configured as follows.

 

 

6. Referrer-Policy

The Referrer-Policy header is used to determine what information is returned in the “Referrer” header. Failure to set an appropriate Referrer-Policy response header can lead to the disclosure of sensitive information to third-party web applications.

The following example ensures that the Referred header is ignored and no information is passed within requests.

 

7. Clear-Site-Data

The Clear-Site-Data header provides functionality for application developers to control which data is persistently stored within the browser’s various storage locations (cookies, storage APIs, cache). This can be useful for web developers, as they can instruct the browser to remove sensitive information stored on the client-side, such as cookies, caches, and storage, during a logout process. Note: This is only supported in secure contexts (HTTPS).

The following example sets the header to clear all types of data.

 

 

8. Cross-Origin-Embedder-Policy

The Cross-Origin-Embedder-Policy (COEP) header can be utilised to prevent a web browser from loading resources from third-party domains that don’t explicitly grant permission using Cross-Origin-Resource-Policy headers.

The following example header configuration can be used so that a document can only load resources from the same origin or those specifically identified as loadable from additional origins.

 

It should be noted that the Cross-Origin-Opener-Policy will need to be set as well. Additional information on the COEP header can be found here.

 

9. Cross-Origin-Opener-Policy

The Cross-Origin-Opener-Policy (COOP) header is used to segregate cross-origin browsing contexts within a web browser. A browsing context is an environment in which a browser displays a document object to the user, for example, a tab, window or iframe. This header is used to prevent a specific set of cross-origin attacks known as XS-Leaks.

The following example header configuration can be used to isolate the browsing context exclusively to same-origin documents. Cross-origin documents are not loaded in the same browsing context.

 

Additional information on the implementation of COEP and COOP headers can be found here.

 

10. Cross-Origin-Resource-Policy

The Cross-Origin-Resource-Policy (CORP) header is used by developers to define whether a user’s browser is able to make requests to an application or web service from a different origin. The header is used to prevent side-channel and Cross-Site Script Inclusion attacks.

The following example header configuration can be used so that only requests from the same origin can read the resource.

 

 

11. Cache-Control

The Cache-Control header is used to instruct browsers and shared caches on how they should cache information. Sensitive information may be cached to local storage where it can be viewed by unauthorised malicious actors on devices such as shared computers in internet cafes.

This header is often misconfigured by still allowing caching even when set or is missing entirely, which can be a problem when users start to access sensitive data on shared devices as described above.

The following example configuration instructs the browser that no caching is allowed, any previously cached resources are cleared and provide support for HTTP/1.0 caches.

 

For more information on HTTP caching, check the Mozilla Developer website here.

 

12. X-XSS-Protection

This header is now deprecated. We see many applications where this is still configured incorrectly. However, there’s a catch. The Content-Security-Policy can be utilised to protect users from XSS attacks, as long as it’s configured appropriately. It’s recommended that if support for legacy browsers isn’t required, this header should be disabled (shown below) and the CSP header used instead.

 

Where this isn’t possible, the X-XSS-Protection header should be enabled.

Web Server Configuration

In the following section, we will look at how to implement the headers described above in several popular web servers, such as Apache, nginx and IIS. However, the configuration of most web servers will be similar and can likely be implemented in a similar way. You should check vendor-specific documentation for more information.

Some software packages, such as WordPress, provide plugins that can be used to easily configure HTTP response headers. However, such plugins can often introduce their own security risks and care should always be taken when downloading and installing third-party plugins.

Apache Server

The Apache extension ‘headers_module’ must be enabled in the Apache configuration to enable the configuration and modification of HTTP response headers within the Apache webserver.

It’s possible to load the module with the following command.

 

Once enabled, you can now add configuration lines to your Apache2 config file. The location of this file may vary depending on the environment and your specific setup. For this demonstration, we will use the 000-default.conf file. However, you should use your own configuration file.

Our configuration file looks like the below.

 

From here, we can now continue to configure the HTTP response headers. For example, should we want to add the X-Frame-Options header to test that the site cannot be loaded into an iframe, we can add this in the format ‘Header Set HEADER-NAME VALUE’.

 

Now, when we access our site, we can see that the X-Frame-Options header is set, and we are blocked from loading this site within an iframe. We can continue in the same manner to add headers and test the application.

 

Please note

All changes to the configuration file require the Apache2 service to be restarted before the changes take effect. When we access our test site with a browser and check the Network tab inside the developer tools, we can see that the response headers set above are now returned by the webserver.

 

Nginx Server

Like the Apache server configuration, nginx requires modification of local config files (nginx.conf) to implement HTTP response headers. For nginx, we can add these in the format ‘add_header HEADER-NAME VALUE’.

After adding the above headers, our configuration file looks like the following:

 

Again, after stopping the Apache web server and starting the nginx web server, we can see that the headers are still applied when accessing the test site.

Internet Information Services (IIS)

IIS can be configured with the IIS Manager. Within the Site, configure the ‘HTTP Response Headers’ setting for the required site. In this demo, we’re using the “Default Web Site”.

 

Once in the HTTP Response Headers setting, configure response headers by right-clicking and choosing “Add…”. Add each header and test as required, once complete you may have something similar to the below.

Restart the IIS service and access your site, you should now see the new HTTP response headers returned in HTTP responses.

HTTP headers are a relatively easy way to improve your application security. Keeping up to date with the most current headers will help you implement security best practices and protect your web application. Stay tuned as we’ll be revisiting HTTP security headers in this blog series to ensure you’re equipped with the knowledge you need to stay secure. If you feel like you need some more assistance, check out our website penetration testing services or contact us today.