6

Mozilla Firefox 4.0 supports something called Content Security Policy that disables the interpretation of embedded Java Script. Only external Java Script files that are referenced using a script tag and that are on a whitelisted domain are executed.

Currently only Mozilla Firefox 4.0 support it, but it is an W3C draft.

Given that rewriting an existing web application to stop using on-attributes is a lot of work, the question arises, if it is worth the trouble.

Is it likely that other browsers will support it? Are there known ways to circumvent the protection (assuming the .js files are static)?

Improve this question

3 Answers 3

Reset to default
7

CSP, along with the HTTP cookie secure flag, HSTS, and X-FRAME-OPTIONS, will forever remain my favorite HTTP response headers for improving the security of users for all time.

Also see -- Enabling Browser Security in Web Applications

Improve this answer
1
  • 1
    You forgot X-XSS-Protection:1;mode=block and X-Content-Type-Options:nosniff
    – Andrei Botalov
    Jul 20, 2012 at 10:27
5

I think this mechanism would have real value only in a specific set of circumstances.

In the general case, of a regular web application, you'd be better just fixing your code to be XSS-safe, as @SteveS wrote.

However, there are some scenarios where that is not easily possible, and these scenarios are growing in popularity. I'm referring to "user-generated content", where you need to allow users to enter (almost) any data at all, including arbitrary HTML content - blogs, social networking sites, CMS, etc...

Now, the security-pro part of me is cringing from that, and right away I wanna jump and shout: "No, you don't need to do that, find a better way!". But of course that's not really the point...
And yes, there are roundabout ways to avoid that situation, with having users enter arbitrary HTML - either whitelisting certain tags, or using an alternate markup system (like Markdown used here) - but those are kind of a kludge, limiting in functionality, and not trivial for some end users.

Bottom line, there will be some webapps that will accept arbitrary HTML, for whatever reason the business deems necessary, and it can be counter-productive to shout about how insecure it is, cuz that just aint gonna work.
In these cases, Content Security Policy can add great value, and mitigate the XSS feature to a great extent.

Improve this answer
3
  • 1
    I think you are on point about it's value and have a great argument, but I still think that it's a feature that developers will rely on to protect the site, rather than writing secure code. With that being said, it adds value for defense-in-depth.
    – Steve
    Apr 4, 2011 at 20:14
  • 1
    @SteveS, I don't disagree - probably true in 8 times out of 10. But, as I wrote, there are those 2 times where the common solutions are not sufficient, and the "secure" solution (without CSP) would be to remove the feature altogether. Not very likely in some sites...
    – AviD ♦
    Apr 5, 2011 at 9:54
  • Seeing this answer over 5 years later, when the state of the art of CSP has advanced a great deal (and so has my understanding) - I feel I should recant the point of this answer... Basically, most of it is still right, the need to fix the XSS first of all... but CSP is not just for specific edge cases, at the very least it is a great defense in depth. But CSP is so rich now, it really enables a lot more control beyond just blocking XSS (e.g. anti-framing...) My bottom line: yes, absolutely use CSP always.
    – AviD ♦
    Jul 25, 2016 at 6:54
1

In theory it's a neat idea, but I think the more important question to ask is: what is this solving? I can see it making life easier for preventing XSS, but you still need to dynamically generate JavaScript, so instead of attacking the page itself, you just attack the .js files. But you said static .js files...

My guess is that it's more trouble than its worth. You would be better off rewriting your code to be XSS-safe than rely on the browser for anything.

Improve this answer
3
  • I think it is possible to avoid dynamic javascript by using jQuery css-selector type rules to add event handlers to the elements that require it. And if the event handlers need additional element specific data, that can be provided within the elements using either css classes or data-attributes.
    – Hendrik Brummermann
    Mar 28, 2011 at 17:57
  • Someone has downvoted this, but there does not seem to be an obvious reason for that. So I am interested in the background.
    – Hendrik Brummermann
    Mar 29, 2011 at 8:26
  • Yeah, I noticed that down vote. I'm curious why too, but ah well.
    – Steve
    Apr 4, 2011 at 20:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .