I'll see your cross site scripting and raise
you a Content Security Policy
Lou Leone :: Rochester OWASP
•
•
•
•
•
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
• 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
• 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)
• 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
• 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…)
• 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
• 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 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?”
• 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
• Policy directives provide for fine-grained content inclusions
rules:
–
–
–
–
–
–
–
–
–
default-src
script-src
object-src
img-src
media-src
style-src
frame-src
font-src
xhr-src
–
–
–
–
–
–
frame-ancestors
report-uri
policy-uri
options
script-nonce (proposed)
sandbox (proposed)
• 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
• img-src
Specifies 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-src
Specifies the safe domains for media and audio element “src”
attributes
• style-src
Specifies the safe domains for the “href” value of <link
rel="stylesheet"> element or <?xml-stylesheet?> directives
• 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)
• frame-ancestors
Specifies domains from which content will be able to utilize the
<iframe>, <frame> or <object> 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
• 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
•
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
• 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
• 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
• 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.
• Mozilla’s overview:
https://developer.mozilla.org/en/Introducing_Content_Security
_Policy
• W3C’s unofficial draft:
https://dvcs.w3.org/hg/content-security-policy/rawfile/tip/csp-specification.dev.html
• Demo scripts and test page:
http://people.mozilla.com/~bsterne/content-securitypolicy/demo.cgi