Page MenuHomePhabricator

Upload SVG checks blacklist filter attributes, even if local to current svg doc
Closed, ResolvedPublic

Description

Get an script/html warning on upload

I got an ERROR unspecific warning: "This file contains HTML or script code that may be erroneously interpreted by a web browser."
After some testing I found the cause.

Here the same fixed file: [[File:Topographic map of Cape Verde-de.svg]] the difference is only the SVG filter attribute presentation which seems only accepted in a style attribute.


Version: 1.24rc
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70937

Attached:

Details

Reference
bz67044

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:36 AM
bzimport set Reference to bz67044.
bzimport added a subscriber: Unknown Object (MLST).

I got an ERROR unspecific warning: "This file contains HTML or script
code that may be erroneously interpreted by a web browser."

Where and how is this displayed? Is this about Special:Upload ?

Yes, it is displayed on upload.

Sorry but the last comment is ambiguous - do you refer to the time or the place? Is this on Commons? Special:Upload or UploadWizard or both?

Sorry I did not think that one has to be so specific. Yes it is on Commons, but that should not matter? And yes it's both, so this does not matter (the Wizard msg is a bit different)? I think there are some attributes left in the SVG restriction upload-"filter", here the SVG attribute "filter" himself (on line 147 in the attachment).

Can you simply upload the file?? (test on simply [[c:File:Test.svg]])

If it's on both, then it's relevant to mention that it's on both.
Thanks for testing it. :)

SVG with filters removed

This is identical to the original SVG file apart with filters removed. Tested at https://commons.wikimedia.org/w/index.php?title=File:Test.svg&oldid=130044706

Attached:

(In reply to Fæ from comment #7)

Created attachment 16060 [details]
SVG with filters removed

This is identical to the original SVG file apart with filters removed.
Tested at
https://commons.wikimedia.org/w/index.php?title=File:Test.svg&oldid=130044706

What is the new information?

Attached:

(In reply to PRO from comment #8)

(In reply to Fæ from comment #7)

Created attachment 16060 [details]
SVG with filters removed

This is identical to the original SVG file apart with filters removed.
Tested at
https://commons.wikimedia.org/w/index.php?title=File:Test.svg&oldid=130044706

What is the new information?

No new information, only that filter effects embedded in SVG files appear to be what cause the rejection on upload to Commons. Removing them from the file source eliminates the problem. See http://www.w3.org/TR/SVG/filters.html

Attached:

Just for reference, I know where the html script error is displayed. Its an upload warning that happens during the upload process. (internally, the uploadscripted message)

So, this limitation was intentional. To quote our code:

  1. image filters can pull in url, which could be svg that executes scripts if ( $strippedElement == 'image' && $stripped == 'filter' && preg_match( '!url\s*\(!sim', $value ) ) { wfDebug( METHOD . ": Found image filter with url: " . "\"<$strippedElement $stripped='$value'...\" in uploaded file.\n" );

    return true; }

However the main intent of this block seems to be to prevent external filters, not filters from the same file.

CSteipp: Would it be ok to relax the filter restriction so it only blacklists external urls, but is ok for things like filter: url( #foo ); and filter: url( '#bar' ); ? This would be similar to how we handle style attributes.

However the main intent of this block seems to be to prevent external
filters, not filters from the same file.

CSteipp: Would it be ok to relax the filter restriction so it only
blacklists external urls, but is ok for things like filter: url( #foo ); and
filter: url( '#bar' ); ? This would be similar to how we handle style
attributes.

Important note I should mention here, is that (based on my reading of the code) we already disallow (externally linking) xlink:href attributes on <filter> elements, so allowing filter="url( '#foo' )" attributes wouldn't be able to get to an external document simply by referencing a <filter> element with xlink:href attribute pointing to another document.

(In reply to Fæ from comment #9)
It seems you overlooked the opening post. But thanks to made more attention to this bug.

(In reply to Fæ from comment #11)
So you can simply fix it? Because the exactly same filter in a style worked!? Or it means that the filter restriction is/was not thorough enough to style="filter:..."? Thank you.

(In reply to PRO from comment #13)

(In reply to Fæ from comment #9)
It seems you overlooked the opening post. But thanks to made more attention
to this bug.

(In reply to Fæ from comment #11)
So you can simply fix it? Because the exactly same filter in a style
worked!? Or it means that the filter restriction is/was not thorough enough
to style="filter:..."? Thank you.

Yes. style="filter: url( #filtera )" is currently allowed (Which is even better reasoning to relax the restrictions on filter= attribute.

Change 150048 had a related patch set uploaded by Brian Wolff:
[DO NOT MERGE] Relax filter attribute filtering to allow self-referential urls

https://gerrit.wikimedia.org/r/150048

Perhelion renamed this task from Scripted SVG checks blacklist all filter attributes, even if local to current svg doc to Upload SVG checks blacklist filter attributes, even if local to current svg doc.Jan 1 2015, 8:44 PM
Perhelion set Security to None.

The linked patch (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/150048/) was merged in 2019, but didn't get a notification here because it used the Bugzilla bug #. Should this be closed now?

Aklapper assigned this task to Bawolff.
Aklapper removed a project: Patch-For-Review.

No reply; assuming so.