Content Security Policy (CSP) example for XSS prevention

Products

Advanced Secure Gateway Software - ASG Secure Web Gateway Virtual Appliance ProxySG Software - SGOS

Issue/Introduction

The Open Web Application Security Project (OWASP) is an international community that develops initiatives to improve software security. OWASP's Top 10 Web Application Security Risks (last defined in 2013) addresses web application security and provides a list of the most critical web application security flaws.

This FAQ shows how to use Content Security Policy (CSP - https://www.w3.org/TR/CSP/) in order to prevent cross-site scripting (XSS).

CSP gets defined on ProxySG and delivered to the browser, where it gets executed.

Resolution

Note: Symantec has developed a Web Application Firewall solution which has been initially released with SGOS 6.6.2.1. For more information, visit https://www.symantec.com/products/web-application-firewall-reverse-proxy

Blue Coat's policy based on CSP

Blue Coat is developing a policy based on the W3C Content Security Policy (CSP) 1.0 recommendation. See the following for information:

Use a recommended policy template
Apply policy directives to a wide variety of resources
Restrictions of using CSP on web browsers
Restrictions of using CSP on web applications
Send a Report-Only header
Caveats
Reference

1. Use a recommended policy template

NOTE: This is also the sample for www.mydomain.com using the strictest CSP.

Instead of blindly trusting everything that a server delivers, specify 'self' as one valid source of script. This sample creates a whitelist of sources of trusted content, and instructs the browser to only execute or render resources from those sources.

<Proxy> … … url.domain=www.mydomain.com action.AddCspHeaders(yes)

; Define list of CSP HTTP Headers
define action AddCspHeaders

;--Disable default source in order to avoid browser fallback loading using 'default-src' locations ;--Define loading policies for Scripts ;--Define loading policies for Plugins ;--Define loading policies for Styles (CSS) ;--Define loading policies for Images ;--Define loading policies for Audios/Videos ;--Define loading policies for Frame ;--Frame + Sandbox : Here sandbox allow nothing, customize sandbox options depending on your browser... ;--Define loading policies for Fonts ;--Define loading policies for Connection ;--Define loading policies for violation Report

append(response.x_header.Content-Security-Policy, “ \ default-src ‘none’; \ script-src ‘self’ <[Other Domain list]>; \ object-src ‘self’ <[Other Domain list]>; \ style-src ‘self’ <[Other Domain list]>; \ img-src ‘self’ <[Other Domain list]>; \ media-src ‘self’ <[Other Domain list]>; \ frame-src ‘self’ <[Other Domain list]>; sandbox; \ font-src ‘self’ <[Other Domain list]>; \ connect-src ‘self’ <[Other Domain list]>; \ report-uri <YOUR Report Parser URI> \ “)

append(response.x_header.X-Content-Security-Policy, “ \ default-src ‘none’; \ script-src ‘self’ <[Other Domain list]>; \ object-src ‘self’ <[Other Domain list]>; \ style-src ‘self’ <[Other Domain list]>; \ img-src ‘self’ <[Other Domain list]>; \ media-src ‘self’ <[Other Domain list]>; \ frame-src ‘self’ <[Other Domain list]>; sandbox; \ font-src ‘self’ <[Other Domain list]>; \ connect-src ‘self’ <[Other Domain list]>; \ report-uri <YOUR Report Parser URI> \ ”)

append(response.x_header.X-WebKit-CSP, “ \ default-src ‘none’; \ script-src ‘self’ <[Other Domain list]>; \ object-src ‘self’ <[Other Domain list]>; \ style-src ‘self’ <[Other Domain list]>; \ img-src ‘self’ <[Other Domain list]>; \ media-src ‘self’ <[Other Domain list]>; \ frame-src ‘self’ <[Other Domain list]>; sandbox; \ font-src ‘self’ <[Other Domain list]>; \ connect-src ‘self’ <[Other Domain list]>; \ report-uri <YOUR Report Parser URI> \ “) end

2. Apply policy directives to a wide variety of resources

CSP also provides a rich set of policy directives that enables fairly granular control over the resources that a page is allowed to load.

script-src restricts which scripts the protected resource can execute.
connect-src limits the origins to which you can connect (via XHR, WebSockets, and EventSource).
font-src specifies the origins that can serve web fonts. Google’s Web Fonts could be enabled via font-src https://themes.googleusercontent.com.
frame-src lists the origins that can be embedded as frames. For example, frame-src https://youtube.com would enable embedding YouTube videos, but no other origins.
img-src defines the origins from which images can be loaded.
media-src restricts the origins allowed to deliver video and audio.
object-src allows control over Flash and other plugins.
style-src is script-src’s counterpart for stylesheets.
report-uri specifies report URIs to which send back to server with a violation report. This requires that the web application set up a URI processing violation report in JSON format.

Refer to the full W3D specification at http://www.w3.org/TR/CSP/#report-uri.

NOTE: A detailed usage for directives is available: http://www.w3.org/TR/CSP/#directives

TIP: Refer to more use cases and CSP samples at http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

3. Restrictions of using CSP on web browsers

Only a subset of Web Browsers support CSP, see the web browser compliant status below As of 2012 CSP is W3C candidate. The following header names are in use as part of experimental CSP implementation:

Content-Security-Policy — Standard header name proposed by the W3C document. Google Chrome supports this as of version 25.
X-WebKit-CSP — Experimental header introduced into Google Chrome and other WebKit-based browsers (Safari) in 2011.
X-Content-Security-Policy — Experimental header introduced in Gecko 2-based browsers (Firefox 4, Thunderbird 3.3, SeaMonkey 2.1).

As of 2013, Firefox only supports the experimental header X-Content-Security-Policy. Instead of the directives 'unsafe-inline' and 'unsafe-eval', Firefox expects the deprecated syntax: options inline-script eval-script.

Support for the sandbox directive is also available in Internet Explorer 10 using the experimental X-Content-Security-Policy header.

To verify the support that target browers provide in order to configure CSP policy, refer to http://caniuse.com/contentsecuritypolicy for a comprehensive CSP compatibility table.

4. Restrictions of using CSP on web applications

Browsers cannot distinguish between content originating from a website and content injected by an attacker; thus, CSP requires the separation of content and code. You may have to make some modifications to your web application to achieve CSP compliance.

Web applications must link to external JavaScript files (*.js) instead of using inline JavaScript.
Web application owners also must provide a list of trusted domains that host the external JavaScript files when composing CSP policies for each website. The whitelist of trusted domains will be added to CSP headers and sent out to browsers. A CSP-compliant browser will execute JavaScript only from these trusted domains.

5. Send a Report-Only header

As a stepping stone to a complete deployment, CSP can ask the browser to monitor a policy, report violations, but not enforce the restrictions. Instead of sending a Content-Security-Policy header, send a Content-Security-Policy-Report-Only header.

NOTE: For Gecko2-based browers, use X-Content-Security-Policy-Report-Only. For Webkit-based browsers, use X-Webkit-CSP-Report-Only.

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

The policy specified in report-only mode won’t block restricted resources, but it will send violation reports to the location you specify. Admin can even send both headers, enforcing one policy while monitoring another.

This is a good way to evaluate the effect of changes to your application’s CSP: Turn on reporting for a new policy, monitor the violation reports, and fix any bugs that turn up. Then, start enforcing the new policy once you’re satisfied with its effect.

The following sample is of a violation report transmitted inside a POST body to a location specified in a report-uri directive, formatted in JSON:

{

"csp-report": {

"document-uri": "http://example.org/page.html",

"referrer": "http://evil.example.com/",

"blocked-uri": "http://evil.example.com/evil.js",

"violated-directive": "script-src 'self' https://apis.google.com",

"original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"

}

For more details on the report-uri directive, refer to http://www.w3.org/TR/CSP/#report-uri.

6. Caveats

Aside from limited browser support, CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as one of the defensive layers to reduce the harm caused by content injection attacks.

Be aware of the two main sources of risk with CSP: setting too permissive policies and policy misconfiguration.