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(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l