1. I'll see your cross site scripting and raise you a Content Security Policy Lou Leone :: Rochester OWASP

2. What Is It Why How Does It Work What Browsers Support It How To Use It Default CSP Restrictions CSP Policy Directives CSP Violation Reports Examples How To Test Unintended Consequences Resources

3. Mozilla’s Content Security Policy is a proposed standard providing a contract between web pages and browsers to control the locations from which browsers will load content Declarative in nature and provides a fine granularity of content inclusion control Designed to be backwards compatible so as not to break browsers that don’t support it Provides reporting of violations to the appropriate issuing domains

4. Motivated by the endless parade of cross site scripting and “clickjacking” exploits that have arisen over the last decade Designed to mitigate: Cross Site Scripting exploits (XSS) “Clickjacking” Packet sniffing attacks (specifically by eliminating inadvertent use of unencrypted data transmission protocols)

5. Prevents XSS and “Clickjacking” by controlling the domains from which Javascript can be loaded, blocking the ability for exploits to force the loading of malicious Javascript (Think whitelist versus blacklist) It also prevents link injection Reduces packet sniffing exposure by forcing content to be exchanged only via HTTPS

6. At present, only FireFox 4 and up support CSP It’s rather hard to glean this information from googling and what not, but there’s a great test page (link at end of presentation) and the following tip versions were verified as failing as of 02 May 2012: Google Chrome Mac Safari Opera Microsoft IE (won’t even run the JS test…)

7. Understand the default restrictions browsers honoring CSP will enact for CSP enabled web pages Understand how multiple policies are interpreted by the browser 3 basic parts to implementing a CSP: Policy Delivery Policy Directives Violation Reports

8. No inline Javascript - all Javascript must be in external files No Javascript URLs - use of “javascript: …” is forbidden Element event handling attributes are disabled - use element.addEventListener() instead eval() is disabled - setTimeout() and setInterval() must be called with functions only - no setInterval(“location=‘yourehacked.org’", 10000) The Function() constructor is disabled - use the function operator or function statement data: URIs are disabled except for images - may be overridden in the X-Content-Security-Policy header XBL binding must use the chrome: or resource: URI specifier policy-uri and report-uri must refer to the issuing domain’s host

9. CSP follows a policy of “least privilege” which means that when multiple policies are present in the content being loaded by the browser, the browser will enforce the most restrictive intersection of the policies received All policies must allow an action to be taken for it to be executed The following issue is being debated: “What should happen when multiple instances of the same directive but with different values occur within a single policy header or meta element, i.e. should they be combined or intersected as they are successively parsed?”

10. Browsers are informed of a CSP by one of two methods: X-Content-Security-Policy Response Header Specifying policy in the header is preferred over the meta element means and takes precedence when both are specified HTML Element The header entry or meta element contains the policy directives for the issuing page

11. Policy directives provide for fine-grained content inclusions rules: – frame-ancestors – report-uri – policy-uri – options – script-nonce (proposed) – sandbox (proposed) – default-src – script-src – object-src – img-src – media-src – style-src – frame-src – font-src – xhr-src

12. default-src Specifies the default safe source domains for all types except frame-ancestors and where not otherwise declared script-src Specifies the safe domains for script element “src” attributes object-src Specifies the safe domains for object element “data” attributes, embed element “src” attributes, and applet element “code”/”archive” attributes

13. img-src Specifies the safe domains for img element “src” attributes, CSS property “url()” and “image()” values, and the “href” value of or elements media-src Specifies the safe domains for media and audio element “src” attributes style-src Specifies the safe domains for the “href” value of element or directives

14. frame-src Specifies the safe domains for iframe element “src” attributes font-src Specifies the safe domains for @font-face CSS rule “src” attributes xhr-src Specifies the safe domains XMLHttpRequest objects are able to communicate with (this appears to be a relaxation of the same origin policy currently honored by XMLHttpRequest objects)

15. frame-ancestors Specifies domains from which content will be able to utilize the, or elements report-uri Specifies the URL for posting the JSON violation report data policy-uri Specifies a URL to load a policy file from and can only be used when no other policy directives are specified using the header or meta element policy delivery mechanism

16. options Provides a means of relaxing the default CSP restrictions script-nonce (proposed) Provides a means to allow inline Javascript to execute sandbox (proposed) Provides a sandbox policy with the same syntax and semantics as the iframe element “sandbox” attribute defined in HTML5

17. Limiting content to the issuing domain: X-Content-Security-Policy: default-src 'self' Allowing images from anywhere, plugin content from a list of trusted providers, and scripts from a specific domain: X-Content-Security-Policy: default-src 'self'; img-src *; \ object-src media1.example.com media2.example.com *.cdn.example.com; \ script-src trustedscripts.example.com Globally denying all third-party scripts and disallowing third-party media by using separate headers: X-Content-Security-Policy: default-src *; script-src 'self‘ X-Content-Security-Policy: default-src *; script-src 'self'; media-src 'self' Ensure all content is loaded over TLS: X-Content-Security-Policy: default-src https://*:443

18. When using the report-uri directive to specify a delivery URL for violation reports, a code-behind to handle the incoming reports must be implemented Violation reports sent to the delivery URL via an HTTP POST of JSON formatted data The JSON contains the following: request : Specifies the HTTP request of the resource whose policy was violated including method/verb, URI and HTTP version request-headers : Specifies the HTTP request headers sent with the request for the protected resource whose policy was violated blocked-uri : Specifies the URI of the resource that was prevented from loading due to the policy violation violated-directive : Specifies which policy directive that was violated original-policy : Specifies the original policies as received by the user-agent and comma separating them if multiple were received Be sure to follow secure programming practices when implementing the code behind the report delivery URL

19. For the policies specified: Inject content that would violate the policies Test in browsers supporting both CSP and not supporting CSP Verify content is not loaded/executed using tracing tools such as Fiddler/Wireshark and client-side debuggers such as FireBug If enforcing HTTPS, verify content is loaded only over secure protocols using a tool such as Wireshark Verify your reporting code is reporting the correct information from the violations (also perform whatever secure coding tests you would for a normal web application) When multiple browsers support CSP, be sure to test policies across supporting browsers

20. Consider: A page provides a script-src policy to allow the inclusion of Javascript from a 3 rd party who does not issue a CSP and has not been included in your CSP. The 3 rd party’s Javascript includes other Javascript files from the 3 rd party’s domain. At a later date the 3 rd party changes where their included Javascript is being loaded from to a domain not specified in the original CSP. The 3 rd party’s functionality is now broken.

21. Mozilla’s overview: https://developer.mozilla.org/en/Introducing_Content_Security _Policy https://developer.mozilla.org/en/Introducing_Content_Security _Policy W3C’s unofficial draft: https://dvcs.w3.org/hg/content-security-policy/raw- file/tip/csp-specification.dev.html https://dvcs.w3.org/hg/content-security-policy/raw- file/tip/csp-specification.dev.html Demo scripts and test page: http://people.mozilla.com/~bsterne/content-security- policy/demo.cgi http://people.mozilla.com/~bsterne/content-security- policy/demo.cgi