Published 16 years 10 months ago • Last updated July 2, 2025 • ⏱️ 2 min read
This is my cup of tea, a whole new way to prevent XSS and related attacks. I've been looking at the specification and I like the core of the policy preventing external scripts, eval etc. But reading it I started to think of ways around it because it's fun :)
The meta tag seems like a bad idea to me, if a site enforced the policy from a http header then a attacker controlled meta tag could merge policy data with an attacker's evil policy.
I'm not sure what this is meant to prevent as the allowed section states it allows setTimeout, setInterval with functions as an argument. So you can do this:- setTimeout(function(){alert(1);//any code}); Or redefine existing functions, I'm not sure that preventing tainted javascript will work this way as there are many ways to obfuscate and execute code.
Finally my other idea was injecting javascript onto itself using a HTML page. This assumes the CSP policy allows scripts to be executed from it's own domain. The attack also relies on the fact that you can control the output of the entire page or the output is in quirks mode with any E4X breaking code. So the vectors would work like so:-
The script is commented out when the HTML is executed because it references itself as javascript.
alert(1)//<script src="#"></script>
Here the script injects itself and the resulting javascript ignores the script tag as inline e4x:-
alert(1);<script src="#"></script>;
Demo's of the vectors are available here:- CSP1 without E4X CSP2 with E4X
I've updated the vectors and made the e4x one more realistic. Here is a Firefox 3.5 version which gets round the "whole program" error by splitting the HTML and inserting a Javascript statement:-
Of course these attacks are theoretical because I've not actually had chance to test CSP, is there a beta? Anyway these vectors could easily be protected by enforcing script content to have the correct headers and not allow HTML data.