Response Header Hardening - Preventing Information Interception and XSS

Response Header Hardening

Preventing Information Interception and XSS

Andrea Hauser
by Andrea Hauser
on March 08, 2018
time to read: 8 minutes

Keypoints

  • The Referrer-Policy header indicates which information is permitted in the referrer header of a request.
  • The Expect-CT header enables the implementation of Certificate Transparency.
  • The X-Permitted-Cross-Domain-Policies header is used to allow PDF and Flash documents for cross-domain requests.
  • The Access-Control-Allow-Origin as well as the Access-Control-Allow-Credentials headers should only be used for trusted sites using a whitelist approach
  • The Public-Key-Pins header should be avoided due to its complexity and dwindling browser support.

This article continues where our previous discussion of response headers left off. We already stressed the importance of this topic two and three years ago. I would now like to focus on some lesser known and newer headers.

Referrer policy

The Referrer-Policy header is a fairly new header that has been a W3C Candidate Recommendation since January 26, 2017. It makes it possible to control which referrer information is included in requests. When viewing a page, the referrer information indicates the origin of the request. Because this can lead to privacy and security issues when passing on the URL, the Referrer-Policy header was created to control how this information is sent from a referring page to the target page in the course of browsing. W3C explains the advantages of the Referrer-Policy header in the following situations, for example:

The specification defines the following values for the Referrer-Policy header:

We recommend using the most restrictive Referrer-Policy setting possible. Ideally, the header settings should be configured as follows:

Referrer-Policy: strict-origin-when-cross-origin;

Expect-CT

This header is currently only supported by Google Chrome and has experimental IETF status. I will still briefly touch upon the concept of this header. In the Chrome Status Platform it is explained as an HTTP header that allows websites to opt in to reporting or enforcement of Certificate Transparency (CT). If the Expect-CT Header is set for a web page, Chrome is told to check whether the website has a certificate in the public Certificate Transparent logs. This prevents fake certificates from being used on this website without being noticed.

X-Permitted-Cross-Domain-Policies

The X-Permitted-Cross-Domain-Policies header is used to permit cross-domain requests from Flash and PDF documents. In most cases, these permissions are defined in an XML document called crossdomain.xml found in the root directory of the web page. For situations in which the root directory cannot be specified, however, this header can be used to define a desired meta policy. The X-Permitted-Cross-Domain-Policies header should ideally be set as restrictively as possible. If integrating Flash and PDF documents via a different domain is to be prevented completely, it is important to ensure that there is no crossdomain.xml file in the web directory and that the header described is configured as follows:

X-Permitted-Cross-Domain-Policies: none;

Access-Control-Allow-Origin and Access-Control-Allow-Credentials

The Access-Control-Allow-Origin header makes it possible to control whether and which external pages are permitted access to the resources on a given web server. Permissions should be kept as restrictive as possible here. The configuration options are either to specify the trusted origin or * if the resource may be accessed by all. The Access-Control-Allow-Credentials header can also be set in addition to the Access-Control-Allow-Origin header if the content is protected using cookies or the Authorization header. Both headers should only be set specifically for trusted pages using a whitelist approach.

Public key pins (HPKP)

The advantages of public key pinning were already discussed in the article Big Brother or How I Stopped Worrying and Love Encryption, which made the following recommendation:

Public-Key-Pins: max-age=5184000; pin-sha256="base64-kodierter-SPKI-Fingerprints" [; includeSubdomains][; report-uri="URI"]

In my opinion, however, this article did not sufficiently address the risks associated with this header. If this header is set with incorrect PINs or the corresponding key is lost, users will be blocked from accessing the page. Because correctly setting this header is not simple and the effects of an incorrect header can be disastrous, using it is no longer recommended. The suggestion Intent To Deprecate And Remove: Public Key Pinning in the Chrome forum reflects this same opinion.

Other response headers

Below you will find the remaining response headers that we have already covered in detail in the past, as well as their recommended configuration. There is also a link to the article providing a more detailed description.

Strict-Transport-Security

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload;

Content-Security-Policy

If the content security policy has not been used before, we recommend starting with the following configuration:

Content-Security-Policy: default-src "none"; script-src "self"; connect-src "self"; img-src "self"; style-src "self";

X-Xss-Protection

X-XSS-Protection: 1; mode=block;

X-Content-Type-Options

X-Content-Type-Options: nosniff;

X-Frame-Options

X-Frame-Options: DENY;

Content-Type

Content-Type: text/html; charset=UTF-8;

To conclude this section, it should be mentioned that it is equally important which headers are not set. For example, X-AspNetMvc-Version, X-AspNet-Version, X-Powered-By and Server can provide hackers with helpful information for attacking a given environment.

Current prevalence of headers

The headers discussed in this article are currently used to varying degrees: the prevalence of the Access-Control-Allow-Origin and Access-Control-Allow-Credentials header was not evaluated because they are not headers that should be found on every page. For this reason, evaluating the prevalence of these headers would not be particularly helpful.

Prevalence of the HTTP Security Header

The evaluation is based on data from Shodan. In each case, a percentage is listed to indicate how many websites use the header. For example, only 0.2538% of all websites around the world contacted via TCP port 80 use the Referrer-Policy header.

About the Author

Andrea Hauser

Andrea Hauser graduated with a Bachelor of Science FHO in information technology at the University of Applied Sciences Rapperswil. She is focusing her offensive work on web application security testing and the realization of social engineering campaigns. Her research focus is creating and analyzing deepfakes. (ORCID 0000-0002-5161-8658)

Links

You need support in such a project?

Our experts will get in contact with you!

×
Deepfake Audio Text to Speech

Deepfake Audio Text to Speech

Andrea Hauser

IT Security Tips

IT Security Tips

Andrea Hauser

GraphQL

GraphQL

Andrea Hauser

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here