On May 27, 2014 11:28 PM, "Matthew Flaschen" <mflaschen(a)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