On May 27, 2014 11:28 PM, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 05/27/2014 09:11 PM, John wrote:
How would this work for non-wmf wikis?
It could be configurable, and default to only allowing content under the
image upload path on the local wiki (if it's enabled at all).
what about executing JavaScript that is posted to a approved wiki? This
would make XSS and a whole host of other
problems a lot easier to do. So we whitelist commons.wikimedia.org whats stopping a user from making a user subpage with some JS code that
executes
something arbitrary?
I specifically said bits.wikimedia.org and upload.wikimedia.org (and not
commons.wikimedia.org), neither of which host user JavaScript.
Matt Flaschen
Gadgets are on bits and they are user controlled. Ditto for mediawiki:common.js et al. (Unless you mean users as in non admins). I see no usecase from allowing from bits. If someone wants an extension asset they can upload it.
Personally i dont understand where this conversation is going
why is js even a concern for librsvg. Does it even support that? Surely xss isnt the main concern about fetching random files from the image scalers.
Im not really familar with what the threat case is for restricting svgs, but making image scalers not be able to access the wider network seems like it would reduce the attack surface significantly.
For the client side of things, i havent looked at svg validation code recently, but dont we have roughly the same security concerns both before and after this?
--bawolff