CRV2 ClientSideCodeContSecPolicy - Revision history

Larry Conklin at 20:57, 15 June 2014

2014-06-15T20:57:00Z

Larry Conklin at 20:55, 15 June 2014

2014-06-15T20:55:00Z

Larry Conklin at 20:39, 15 June 2014

2014-06-15T20:39:02Z

Larry Conklin: Created page with "Content Security Policy (CSP). Is an W3C specification offering the possbility to instruct the client browser from which location and/or which type of resources are allowed t..."

2014-06-15T20:37:57Z

Created page with "Content Security Policy (CSP). Is an W3C specification offering the possbility to instruct the client browser from which location and/or which type of resources are allowed t..."

New page

Content Security Policy (CSP).

Is an W3C specification offering the possbility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behavior, the CSP specification use "directive" where a directive defines a loading behavior for a target resource type.

Directives can be specified using HTTP response header (a server may send more than one CSP HTTP header field with a given resource representation and a server may send different CSP header field values with different representations of the same resource or with different resources) or HTML Meta tag, the HTTP headers below are defined by the specs:

* Content-Security-Policy : Defined by W3C Specs as standard header, used by Chrome version 25 and later, Firefox version 23 and later, Opera version 19 and later.

* X-Content-Security-Policy : Used by Firefox until version 23, and Internet Explorer version 10 (which partially implements Content Security Policy).

* X-WebKit-CSP : Used by Chrome until version 25

== Risk ==
The risk with CSP can have 2 main sources:
# Policies misconfiguration,
# Too permissive policies.

This page lists useful security-related HTTP headers. In most architectures these headers can be set in web servers configuration ([http://httpd.apache.org/docs/2.0/mod/mod_headers.html Apache], [http://technet.microsoft.com/pl-pl/library/cc753133(v=ws.10).aspx IIS]), without changing actual application's code. This offers significantly faster and cheaper method for at least partial mitigation of existing issues, and an additional layer of defense for new applications.

{| border="1"
|-
! Header name
! Description
! Example
|-
|[http://tools.ietf.org/html/rfc6797 Strict-Transport-Security]
|HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This reduces impact of bugs in web applications leaking session data through cookies and external links and defends against Man-in-the-middle attacks. HSTS also disables the ability for user's to ignore SSL negotiation warnings.
|<code>Strict-Transport-Security: max-age=16070400; includeSubDomains</code>
|-
| [http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01 X-Frame-Options], [http://tools.ietf.org/html/draft-ietf-websec-frame-options-00 Frame-Options]
| Provides [[Clickjacking]] protection. Values: ''deny'' - no rendering within a frame, ''sameorigin'' - no rendering if origin mismatch, ''allow-from: DOMAIN'' - allow rendering if framed by frame loaded from ''DOMAIN''
| <code> X-Frame-Options: deny</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx X-XSS-Protection]
| This header enables the [[Cross-site scripting]] (XSS) filter built into most recent web browsers. It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.
| <code>X-XSS-Protection: 1; mode=block</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx X-Content-Type-Options]
| The only defined value, "nosniff", prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to [http://code.google.com/chrome/extensions/hosting.html Google Chrome], when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.
| <code> X-Content-Type-Options: nosniff </code>
|-
|[http://www.w3.org/TR/CSP/ Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP]
|[[Content Security Policy]] requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including [[Cross-site scripting]] and other cross-site injections.
|<code>Content-Security-Policy: default-src 'self'</code>
|-
| [http://www.w3.org/TR/CSP/ Content-Security-Policy-Report-Only]
| Like Content-Security-Policy, but only reports. Useful during implementation, tuning and testing efforts.
| <code>Content-Security-Policy-Report-Only: default-src 'self'; report-uri http://loghost.example.com/reports.jsp</code>
|}

References:
Apache: http://httpd.apache.org/docs/2.0/mod/mod_headers.html
IIS : http://technet.microsoft.com/pl-pl/library/cc753133(v=ws.10).aspx

@@ Line 1: / Line 1: @@
-Content Security Policy (CSP).
+==Content Security Policy (CSP).==
 Is an W3C specification offering the possbility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behavior, the CSP specification use "directive" where a directive defines a loading behavior for a target resource type. CSPt helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware
@@ Line 16: / Line 16: @@
 # Too permissive policies.
 Code reviewer needs to understand what content security policies were required by application design and how these polices were tested to ensure they are in use by the application.
-This page lists useful security-related HTTP headers. In most architectures these headers can be set in web servers configuration ([http://httpd.apache.org/docs/2.0/mod/mod_headers.html Apache], [http://technet.microsoft.com/pl-pl/library/cc753133(v=ws.10).aspx IIS]), without changing actual application's code. This offers significantly faster and cheaper method for at least partial mitigation of existing issues, and an additional layer of defense for new applications.
+==Useful security-related HTTP headers==
 {| border="1"