First, as I expected, this proposal is to use CSP with the "unsafe-eval" option enabled for both style-src and script-src. This means the JavaScript eval() function can be used freely, and inline CSS via the style attribute can still be used. Combined with the "default-src *" policy, which I mention later in this email, this means an attacker can just use XHR to download an external script and eval() it, thus defeating the entire point of CSP: to prevent XSS attacks.
I understand the reason behind this is because we store scripts in localStorage as cache and eval() them upon page load (which is perhaps the worst abuse of browser technology I have ever seen). Not allowing both inline scripts and styles and eval()ed code is one half of the two-sided CSP coin, and eliminating it keeps open a pretty large attack vector. I don't believe it's appropriate to sacrifice security for a quick kludge that is used to improve the performance hole opened by the large fragmentation of our JavaScript codebase.
Second, the proposal is to use the nonce-$RANDOM attribute for inline scripts, but to cache the nonce for non-logged-in users. Does this mean that the same nonce will be delivered to multiple pages and/or users? Because that is a violation of the CSP spec, which says "If a server delivers a nonce-source expression as part of a police, the server MUST generate a unique value each time it transmits a policy." [0] Thus we cannot use nonces in this way. Are these scripts whose contents we know beforehand? Because then we can just use the hash-source policy.
(Not to mention that nonce-source and hash-source policies are part of CSP 2, which is not supported in the latest IE, Safari, or Opera Mini. What is the plan to support these browsers? Fall back to unsafe-inline? Possibly use a solution similar to what Dropbox used for their CSP deployment [1].)
Finally, as stage 1 hints at and as I mentioned above, there are a lot more than just style-src and script-src, such as font-src, media-src, frame-src, manifest-src, etc. Why are these not addressed, and instead just left to the default policy of "default-src *"? Do we allow iframes on Wikipedia pointing at arbitrary domains? At the very least, a scheme-source policy can be used to enforce HTTPS.
[0] https://w3c.github.io/webappsec-csp/ [1] https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Mon, May 23, 2016 at 1:18 AM, Pine W wiki.pine@gmail.com wrote:
With the disclaimer that I'm not a security engineer and that I understand only parts of this proposal, in general this strikes me as a good idea. It seems to me that trying to develop a comprehensive list of what tools / scripts this proposal would likely break, how important those breaks are, and who could fix them and when, would help with developing a roadmap toward implementing this proposal with appropriate mitigation and communication.
It seems to me that this is the kind of project for which product community liasons are well suited to help with developing and implementing a rollout plan. Is there any chance of getting a CL to help with this project?
Thanks for the initiative,
Pine
Pine On May 22, 2016 18:18, "Brian Wolff" bawolff@gmail.com wrote:
So the RFC process page says I should email wikitech-l to propose an RFC, thus:
Content-Security-Policy (CSP) header is a header that disables certain javascript features that are commonly used to exploit XSS attacks, in order to mitigate the risks of XSS. I think we could massively benefit from using this technology - XSS attacks probably being the most common security issue in MediaWiki. The downside is that it would break compatibility with older user scripts.
Please see the full text of my proposal at
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
The associated phabricator ticket is: https://phabricator.wikimedia.org/T135963
I'd appreciate any comments anyone might have.
Thanks, Brian
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l