Mozilla's Content Security Policy
Mozilla's Content Security Policy
Posted Jul 2, 2009 14:27 UTC (Thu) by butlerm (subscriber, #13312)Parent article: Mozilla's Content Security Policy
being incorrectly coded to output large user submitted text fields without
encoding or user submitted html content without sanitization checks, the
added value of this system is approximately zero.
Enabling this policy also makes it effectively impossible to use
dynamically generated javascript without generating a bunch of little
temporary files, and forcing the web browser to submit secondary requests
to fetch them. That has major performance implications due to turn around
latency. It also seriously complicates the application development
process.
For applications produced in an environment where developers are unaware or
unable to follow basic security practices, or where even a temporary
unpatched "XSS" vulnerability is a serious matter, it would be far better
to propose an extension where script tags needed to carry an attribute with
a generated value that matched a value supplied in the HTTP response
headers.
That would effectively eliminate any real possibility of the web browser
executing a hostile user submitted script, do to the impossibility of
predicting a match, and the change in the generated value on every request.
Mozilla's Content Security Policy
Posted Jul 2, 2009 17:17 UTC (Thu)
by joey (guest, #328)
[Link] (2 responses)
I think you're probably right, which is a real pity, since sanitizing user-supplied html to remove all possible means of javascript injection is very tricky.
Posted Jul 2, 2009 17:17 UTC (Thu) by joey (guest, #328) [Link] (2 responses)
I wish this CSP could be turned on at a block level. Something like:
<csp="no-javascript"> user supplied html here </csp>
Mozilla's Content Security Policy
Posted Jul 2, 2009 17:19 UTC (Thu)
by joey (guest, #328)
[Link]
BTW, right after I posted that, I found a javascript stripping bug in lwn.net, which I've emailed to Jon. :-/
Posted Jul 2, 2009 17:19 UTC (Thu) by joey (guest, #328) [Link]
Mozilla's Content Security Policy
Posted Jul 11, 2009 19:09 UTC (Sat)
by tulcod (guest, #59536)
[Link]
Posted Jul 11, 2009 19:09 UTC (Sat) by tulcod (guest, #59536) [Link]
What Mozilla proposed is not a solution either, though: there is no reason users cannot upload scripts to a host. Heck, websites on most free webhosts would still be vulnerable. I think a better solution would be to only allow javascript to exist in the <head> tag, although this wouldn't be a solution for websites which, for whatever weird reason, would allow users to put stuff in the <head> of a webpage. XSS is an inherent problem with launching scripts from editable content. It would be better to disallow <script> tags completely and use a different mechanism to use javascript on a webpage alongside the HTML delivery, but that would mean properties like onclick and onmouseover would also have to be banned, which induces some rather serious limitations (read: webmasters won't like this).
For now, I'll stick with bbcode and some url encoding.
ps: wow, "webmasters". when was the last time I used that phrase?
Mozilla's Content Security Policy
Posted Jul 9, 2009 13:03 UTC (Thu)
by swiftone (guest, #17420)
[Link]
Posted Jul 9, 2009 13:03 UTC (Thu) by swiftone (guest, #17420) [Link]
Unless your application has a large number of places that are vulnerable to being incorrectly coded to output large user submitted text fields without encoding or user submitted html content without sanitization checks, the added value of this system is approximately zero.
Any site that accepts user input has places that are vulnerable to being incorrectly coded. And as simple as correct coding is it doesn't take much effort to discover that a large number of sites are doing poorly at doing so, either because it turns out that cleansing input is non-trivial after all, or because it is easy to be lazy.
It takes only one developer to screw up in one place to leave a site vulnerable. Because of attacks like Cross Site Request Forgery (Generating a request to a different app that the user is authenticated to) a developer on one app can leave another otherwise secure app vulnerable.
This policy allows the server administrator to greatly reduce the threat in a single fell-swoop. I would not call that added-value "zero".
Meanwhile the cost is:
- No inline JS - Not a problem, inline JS in considered a poor practice in terms of accessibility and maintenance. Use progressive enhancement techniques anyway.
- JS in outside files - Again, a best practice in terms of maintenance and code-reuse.
It is true that this makes dynamically generated javascript difficult. Who (outside of attackers) uses dynamically generated javascript? With the large array of stable and useful JS lubraries available, there should be no need for such butchery. (JSON parsers/generators are specifically mentioned as not being a problem in the CSP FAQ). Is there some bastion of useful dynamically generated JS that I am unaware of?