Mozilla Content SecurityPolicy2012I'll see your cross site scripting and raise you a Content Security Policy

Lou Leone :: Rochester OWASP

Agenda• 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

CSP: What Is It• 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

CSP: Why• 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)

CSP: How Does It Work• 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

CSP: What Browsers Support It• 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…)

CSP: How To Use It• 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

CSP: Default Restrictions• 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

CSP: Multiple Policy Interpretation• 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?”

CSP: Policy Delivery• 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• <meta http-equiv="X-Content-Security-Policy">

HTML Element

• The header entry or meta element contains the policy directives for the issuing page

CSP: Policy Directives• 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

CSP: Policy Directives

• default-srcSpecifies the default safe source domains for all types except frame-ancestors and where not otherwise declared

• script-srcSpecifies the safe domains for script element “src” attributes

• object-srcSpecifies the safe domains for object element “data” attributes, embed element “src” attributes, and applet element “code”/”archive” attributes

CSP: Policy Directives

• img-srcSpecifies the safe domains for img element “src” attributes, CSS property “url()” and “image()” values, and the “href” value of <link rel="icon"> or <link rel="shortcut icon"> elements

• media-srcSpecifies the safe domains for media and audio element “src” attributes

• style-srcSpecifies the safe domains for the “href” value of <link rel="stylesheet"> element or <?xml-stylesheet?> directives

CSP: Policy Directives

• frame-srcSpecifies the safe domains for iframe element “src” attributes

• font-srcSpecifies the safe domains for @font-face CSS rule “src” attributes

• xhr-srcSpecifies 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)

CSP: Policy Directives

• frame-ancestorsSpecifies domains from which content will be able to utilize the <iframe>, <frame> or <object> elements

• report-uriSpecifies the URL for posting the JSON violation report data

• policy-uriSpecifies 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

CSP: Policy Directives

• optionsProvides 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

CSP: Examples• 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

CSP: Violation Reports• 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

CSP: How To Test• 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

Unintended Consequences• Consider:

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

Resources

• Mozilla’s overview: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

• Demo scripts and test page:http://people.mozilla.com/~bsterne/content-security-policy/demo.cgi