Content Security Policy (CSP) is Growing Up.

Published: 2014-09-10
Last Updated: 2014-09-10 23:58:03 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

We have talked here about Content Security Policy (CSP) in the past. CSP is trying to tackle a pretty difficult problem. When it comes to cross-site-scripting (XSS), the browser and the user is usually the victim, not so much the server that is susceptible to XSS. As a result, it makes a lot of sense to add protections to the browser to prevent XSS. This isn't easy, because the browser has no idea what Javascript (or other content) to expect from a particular site. Microsoft implemented a simple filter in IE 8 and later, matching content submitted by the user to content reflected back by the site, but this approach is quite limited.

CSP is an attempt to define a policy informing the browser about what content to expect from a site. Initially, only Firfox supported CSP. But lately, CSP has evolved into a standard, and other browsers started to implement it [1]. The very granular langauge defined by CSP allows sites to specify exactly what content is "legal" on a particular site.

Implementing CSP on a new site isn't terrible hard, and may actually lead to a cleaner site. But the difficult part is to implement CSP on existing sites (like this site). Sites grow "organically" over the years, and it is difficult to come back later and define a policy. You are bound to run into false positives, or your policy is relaxed to the point where it becomes meaningless.

Luckily, CSP has a mechanism to help us. You are able to define a "Report URL", and browsers will report any errors they encounter to said URLs. The reports are reasonably easy to read JSON snippets including the page that caused the problem, the policy they violated, and even an excerpt from the part of the page that caused the problem.

Recently, a few nice tools have cropped up to make it easier to parse these reports and build CSPs. For example Stuart Larsen implemented "CASPR" [2], a plugin for Chrome that was built to create CSPs and to analyze the reports. Tools like this make implementing CSPs a lot easier. 

Any other tools or resources you like to help implementing CSPs?

Update: We got a couple of additional resources in via Twitter:

Using "Virtual Patching" to implement CSP on your Web Application Firewall
Twitter account focusing on CSP: http://twitter.com/SeeEssPee

Thanks to @imeleven for pointing out that Firefox was the first browser to support CSP. He also pointed to this slide deck: http://www.slideshare.net/imelven/evolving-web-security-model-v11-portland-owasp-may-29-2014

â??

 

[1] http://www.w3.org/TR/CSP/
[2] http://caspr.io

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords: CASPR CSP
3 comment(s)

Comments

Chrome applies CSP to extensions. This means:
- Extensions can be sandboxed by local CSP policy
- A web site can profile users' installed extensions

With all browsers, certain spyware, greasemonkey-type scripts, and man-in-the-browser malware can be identified and blocked.

I also found this very interesting: http://homakov.blogspot.com/2014/01/using-content-security-policy-for-evil.html
Since CSP is a client-side technology implemented in the browser, it's simple enough for someone who is intentionally running scripts in an "unauthorized" context to circumvent.

See http://brianmayer.com/2012/12/defeating-chromes-content-security-policy-header-via-a-chrome-extension/
The scope of CSP is to defend the user, not the server. The attacks CSP protects against (most notably XSS) do attack the user and use the server to deliver the malicious content to the user. CSP give the user's browser a chance to detect XSS.

If you want to bypass CSP, you can also use netcat as a browser, or any browser that doesn't support CSP. It doesn't defend against malicious users, it defends users from becoming the victims.

Diary Archives