November 19, 2009 - 18:53 UTC - Tags: security xss csp policy
When it was first introduced, Mozilla Content Security Policy (CSP) seemed at bit interesting when developing new applications, but I couldn't really see any benifit for already existing apps, as they would have they would have to rewrite a lot of the code. However after many of the newer additions, I think this can help severely reduce the effect of many attacks.
Limiting script
Originally it seemed Mozilla CSP would only restrict javascript for some parts of the page. The gist of it seemed to be that you would setup a seperate javascript domain, and all javascript would have to come from that domain to run on your page. While this would work if you completely rewrote you entire website and used a good library like jQuery to wire up the events, it would fit many existing apps, as they frequently use onclick-events etc. directly coded on the html tag attributes. However you could set the javascript domain to limit scrips to your website domain, and thus prevent the attacker from injecting links to evil javascript files (like mitigating attacks with content security policy pointed me in the direction of examples like these:
Header mode:
As you can see from these examples, they allow you to restrict not only scripts, but also other types of content. Why is this interesting? Let's look at a typical attack.
Honeynor has some descriptions here and here. Typically the attacker injects a script-tag or an iframe through XSS or SQL-injection. This is terms loads a lot of other scripts, iframes and objects, which eventually try to break exploit flaws in the browser or plugins (e.g. flash, adobe reader or activex) and gain access of the victim's computer. And all these iframes and scripts are loaded in such a way (hidden with css) that the user cannot see it.
Now CSP allows you to restrict which iframes/frames, scripts and objects the browser should download when running in the context of your site. So by limiting these thre content types, even if you have an XSS flaw somewhere on your site, the attacker cannot use it to perform the attack described above. The attacker would still be able to do a javascript redirect, but at least the URL would change, and the attacks would have to be rewritten to look like the attacked site. So at least it can make the attacks harder to perform.
While Mozilla doesn't solve all problems, it's certainly a step in the right direction. I'm looking forward to Firefox 3.7, and I hope IE9 and new version of Chrome will include this as well. And if they do, please take the time to set the policies for your site.
Comments closed for this post
Limiting script
Originally it seemed Mozilla CSP would only restrict javascript for some parts of the page. The gist of it seemed to be that you would setup a seperate javascript domain, and all javascript would have to come from that domain to run on your page. While this would work if you completely rewrote you entire website and used a good library like jQuery to wire up the events, it would fit many existing apps, as they frequently use onclick-events etc. directly coded on the html tag attributes. However you could set the javascript domain to limit scrips to your website domain, and thus prevent the attacker from injecting links to evil javascript files (like mitigating attacks with content security policy pointed me in the direction of examples like these:
Header mode:
X-Content-Security-Policy: allow self; img-src *; object-src media1.com media2.com; script-src userscripts.example.comMeta-tag mode:<meta http-equiv="X-Content-Security-Policy" content="allow self; img-src *; object-src media1.com media2.com; script-src userscripts.example.com" />As you can see from these examples, they allow you to restrict not only scripts, but also other types of content. Why is this interesting? Let's look at a typical attack.
Honeynor has some descriptions here and here. Typically the attacker injects a script-tag or an iframe through XSS or SQL-injection. This is terms loads a lot of other scripts, iframes and objects, which eventually try to break exploit flaws in the browser or plugins (e.g. flash, adobe reader or activex) and gain access of the victim's computer. And all these iframes and scripts are loaded in such a way (hidden with css) that the user cannot see it.
Now CSP allows you to restrict which iframes/frames, scripts and objects the browser should download when running in the context of your site. So by limiting these thre content types, even if you have an XSS flaw somewhere on your site, the attacker cannot use it to perform the attack described above. The attacker would still be able to do a javascript redirect, but at least the URL would change, and the attacks would have to be rewritten to look like the attacked site. So at least it can make the attacks harder to perform.
While Mozilla doesn't solve all problems, it's certainly a step in the right direction. I'm looking forward to Firefox 3.7, and I hope IE9 and new version of Chrome will include this as well. And if they do, please take the time to set the policies for your site.
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
