CRV2 SecCommsHTTPHdrs - Revision history

Gary David Robinson at 17:33, 15 February 2015

2015-02-15T17:33:35Z

Gary David Robinson at 17:21, 15 February 2015

2015-02-15T17:21:01Z

Gary David Robinson at 16:29, 15 February 2015

2015-02-15T16:29:00Z

Gary David Robinson at 16:03, 15 February 2015

2015-02-15T16:03:22Z

Gary David Robinson at 17:51, 2 February 2015

2015-02-02T17:51:20Z

Gary David Robinson at 09:07, 26 January 2015

2015-01-26T09:07:44Z

Gary David Robinson: Created page with "= 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 provide..."

2015-01-26T08:53:45Z

Created page with "= 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 provide..."

New page

= 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:

# Headers can only be trusted over a HTTPS session
# 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.

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.

== What to Review ==

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

== References ==

@@ Line 142: / Line 142: @@
 == What to Review ==
-When reviewing code modules from an HTTP header sercurity point of view, some common issues to look out for include:
+When reviewing code modules from an HTTP header security point of view, some common issues to look out for include:
+* Do not perform security decisions based on client request HTTP headers (apart from the cookie headers specified as HTTPOnly)
+* Do not trust request headers not passed over HTTPS connections.
+* Ensure you validate the format (length, characters, etc) of the header value before processing it.

← Older revision		Revision as of 17:21, 15 February 2015
Line 112:		Line 112:
	This reporting feature can be used to determine any attacks occurring on your content. Also note that if you specify HTTPS in the report-uri scheme, and the receiver URI is on the current web server, the report JSON can be authenticated as the cookie will be passed over the secure session.		This reporting feature can be used to determine any attacks occurring on your content. Also note that if you specify HTTPS in the report-uri scheme, and the receiver URI is on the current web server, the report JSON can be authenticated as the cookie will be passed over the secure session.

−	trail...	+	If you simply wish to trail the CSP headers, i.e. not actually have the browser enforce the constraints encase it breaks anything, you can instead use the "Content-Security-Policy-Report-Only" header. This will tell the browser to understand the directives and monitor for policy violations, but in the case of a violation the browser will still render the page as if the header was not specified, instead it will send the JSON report. This is a great way to trail the CSP headers on live traffic to see what breaches are currently occurring, or to ensure you have configured your CSP headers before deployment. An example of this is:
−
−

		+	Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp_receiver;

@@ Line 110: / Line 110: @@
+  }
-This reporting feature can be used to determine any attacks occurring on your content.  Also note that if you specify HTTPS in the report-uri scheme, and the
+This reporting feature can be used to determine any attacks occurring on your content.  Also note that if you specify HTTPS in the report-uri scheme, and the receiver URI is on the current web server, the report JSON can be authenticated as the cookie will be passed over the secure session.
 === HTTP Strict Transport Security ===

@@ Line 11: / Line 11: @@
 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:
+Two points to note up front:
 # Headers can only be trusted over a HTTPS session
@@ Line 34: / Line 34: @@
 === 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
+Cross Site Scripting (XSS) is still one of the most frequent security issues 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. Content Security Policy headers are designed to allow a web site to inform the browser where scripts, frames, etc can be sourced from, and are a good way of mitigating XSS issues.
 === HTTP Strict Transport Security ===

@@ Line 17: / Line 17: @@
 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.
 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.
@@ Line 29: / Line 32: @@
+=== 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.
@@ Line 51: / Line 55: @@
    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.
+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.
@@ Line 62: / Line 66: @@
 When reviewing code modules from an HTTP header sercurity point of view, some common issues to look out for include:
-−
+*
@@ Line 68: / Line 74: @@
 * https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

← Older revision		Revision as of 09:07, 26 January 2015
Line 36:		Line 36:


		+
		+	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.


Line 46:		Line 66:

	== References ==		== References ==
		+
		+	* https://www.owasp.org/index.php/HTTP_Strict_Transport_Security