On Thu, Jun 19, 2014 at 11:15 PM, "Christian Müller" <cmue81(a)gmx.de>
wrote:
Sent:
Dienstag, 27. Mai 2014 um 21:21 Uhr
From: "Chris Steipp" <csteipp(a)wikimedia.org>
To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] SVG linking of external images/bitmaps - xlink:href should
support http(s) resources
On Tue, May 27, 2014 at 9:37 AM, "Christian Müller" <cmue81(a)gmx.de>
wrote:
[..] Trusting an image library to correctly speak http
without a memory corruption seems a little scary as well, but I'll admit I
haven't looked at librsvg's code myself.
In any case, it'd be the image library to fix. Restricting access is an
arguably crude workaround due to diffuse fears. It breaks the standard
and makes technology less useful to its users.
[..], if there are any
major browsers that will pull those resources in and let an attacker see
the user's IP address, we shouldn't allow that... hmm, and now that I read
the bug, I see this is firefox'es behavior in the image you uploaded. We
probably want to block that behavior.
Yeah, Firefox's decision to adhere fully to the SVG standard is right imho,
since it has to measure itself in compatibility tests with other browsers.
If WP decides to cripple the standard for security reasons, that's their
beer, but please stop starting to cripple user browsers. Security of that
is in the hand of users, they have to make the decision wich browser to
use and whether that ought to be a security enhanced one with less standard
compliance, or a full featured one like FF.
I meant that because those browsers are fully implementing the spec,
MediaWiki needs to protect our users privacy in case that is used. We
have no influence over Firefox development, and I agree, the browsers
should implement the spec. We just need to ensure we are taking
precautions in that context.
Allowing a whitelist of WMF domains via https may
be possible. In general,
the security checking we do on uploaded files is complex enough that I
don't like adding another layer of specific checks and exceptions, but if
we can find a relatively simple way to do it that maintains our security
and privacy requirements, then I wouldn't stand in the way.
Ok, within WP scope, hosting external dep files on foreign servers is out
of reach, security- and longlivety-wise - it seems everyone agrees on this.
Afai am concerned, two short-term achievable issues remain:
1) allow certain WMF domains via https for thumbnail generation and librsvg
processing in general - this is to adhere to SVG standard, as long as
dependant files remain in wikimedia universe.
(Is there a chance for this to make it into 1.24git?)
Like I said, if someone can find a simple way to do this, we can allow
it in MediaWiki. If someone wants to work on it, one of the first
steps is to get the security/privacy requirements defined (along with
the function requirements, like cscott brought up in the reference
below). Most have been brought up here or on that bug, but someone
should distill those somewhere.
2) fixing chunked upload to not bail out on chunks
that are exclusively
base64 encoded and hence make valid files that include this base64
chunk fail on upload - with an unusable error description.
This will unfortunately require a different approach to how we do
stashed/chunked uploads. Currently, each chunk is actually available
from the server as a file. So each piece has to be checked for xss
vectors, which is why your chunks currently fail. The stash will need
to be inaccessible to end users.
Farther off might be the need to rethink part of the
file infrastructure,
to either broadly allow formats that are not self contained OR make a
strong and reasoned decision against that and document it for wikipedians.
This has been suggested here:
http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076700.html
Regards,
Christian
ps:
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l