Revision as of 17:51, 2 February 2015

This is a draft version

Overview

HTTP headers allow the server to dictate or advise the user agent and intermediary servers how to handle the content being provided. Some of these headers can aid a web site in securing itself; these include the standard Cache-Control headers, and newer specifications like HSTS and Content Security Policy headers.

Description

From a security point of view controlling the HTTP headers sent with web site content can tell the users browser how to store the content, how to access further content, and how to trust various parts of the content received by the browser.

Two point to note up front:

1. Headers can only be trusted over a HTTPS session
2. This section only covers HTTP response headers

Without HTTPS between the web server and the users browser an attacker can modify the content or the associated headers. Thus if you were returning headers specifying that your web site should only be access over HTTPS, an attacker could remove these headers and the browser would not receive the information. A web site should not trust HTTP request headers for security decisions as there are many ways an attacker could modify these headers (or construct the whole request themselves), so there is nothing to cover for secure headers coming from the client, as they are inherently insecure. Of course the cookie header is an exception to this, but that is because our web site has set the cookie header to a random value that should only be known during the browsing session. This section will not cover the cookie header as this is covered in the session management topic.

Caching Headers

For business web sites that allow sensitive or confidential information to be downloaded to the client device, the caching of that sensitive data will become a security issue. A user accessing their bank account details does not want an intermediary proxy caching their web pages. A legal web site does not want copies of sensitive PDF documents stored on the laptop or smartphone disk storage, only for that device to be lost and the documents visible to an attacker.

The 'Cache-Control' header tells the users browser how to handle the content being downloaded. Some browsers can interpret the header values differently thus the understood header settings to return with content that must not be cached are:

Cache-Control: no-store, no-cache
Pragma: no-cache
Expires: 0

This should be understood by all browsers (including mobile webviews) that the content being returned must not be stored to disk cache. Note that it is possible for intermediate proxies to ignore caching headers and still cache the content, which is another reason why using end-to-end HTTPS sessions is important, as the proxies will only have encrypted versions of the sensitive content.

Content Security Policy

Cross Site Scripting (XSS) is still one of the most frequent security issue experienced on web sites, it's A3 on the OWASP Top 10 (2013), and it covers a variety of ways attackers can bypass the browser same origin policy to trick the browsers into executing the attackers code. TBD

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. When the browser receives the HSTS header it will prevent any subsequent requests from being sent over HTTP to the web site, instead only using HTTPS, for the timeframe specified in the header. It also prevents HTTPS click through prompts on browsers.

Simple example, using a long (1 year) max-age:

 Strict-Transport-Security: max-age=31536000

If all present and future subdomains will be HTTPS:

 Strict-Transport-Security: max-age=31536000; includeSubDomains

If the site owner would like their domain to be included in the maintained by Chrome (and used by Firefox and Safari), then use:

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

The 'preload' flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.

Use caution when setting excessively strict STS policies. Including subdomains should only be used in environments where all sites within your organization for the given domain name require ssl. Max-age limits should be carefully considered as infrequent visitors may find your site inaccessible if you relax your policy.

Before enabling includeSubDomains, also consider the impact of any existing DNS CNAME records for CDNs, email services, or other 3rd party services. Since includeSubDomains will force such CNAME subdomains to https:// it's likely the browser will throw a domain-mismatch error, which is hard to reverse because of the browser caching nature of HSTS.

What to Review

When reviewing code modules from an HTTP header sercurity point of view, some common issues to look out for include:

References

• https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
• http://content-security-policy.com/
• http://www.html5rocks.com/en/tutorials/security/content-security-policy/
• http://www.w3.org/TR/CSP/