SVGs fail to render silently if they contain an <image /> element


Author: ejsanders

Obviously the <image /> element is disabled, but it should be stripped, or at
least alert the user to the problem, as many users don't know why their SVGs
aren't rendering.

Version: unspecified
Severity: normal
See Also:

bzimport added a project: Wikimedia-SVG-rendering.Via ConduitNov 21 2014, 8:52 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz3537.
bzimport created this task.Via LegacySep 23 2005, 1:25 PM
brion added a comment.Via ConduitSep 23 2005, 11:34 PM

<image> is supported, but only for embedded data: urls.

bzimport added a comment.Via ConduitSep 24 2005, 12:30 PM

ejsanders wrote:

I don't understand: failed to
render the first version, the new version works and the only change was the that
I removed the <image /> element.

brion added a comment.Via ConduitSep 25 2005, 6:08 AM

Let's look at that <image>:

   sodipodi:insensitive="1" />

Notice how the url it uses to reference the image resource is a
relative path, *not* an embedded data: url. It refers to an external
file, which:

  1. Is not allowed by our security policy on the renderer.
  2. Wouldn't work anyway since the referenced file wouldn't be there.
bzimport added a comment.Via ConduitSep 26 2005, 8:45 AM

ejsanders wrote:

The bug isn't that the <image> doesn't work, but that it fails silently. It
should either strip disallowed image elements then render, or alert the user to
the violation of the security policy, so they can fix the image.

brion added a comment.Via ConduitSep 26 2005, 7:28 PM

Yes, that's why the bug hasn't been closed. :)

You asked why a particular image failed.

bzimport added a comment.Via ConduitSep 26 2005, 7:54 PM

ejsanders wrote:

(In reply to comment #5)

Yes, that's why the bug hasn't been closed. :)

You asked why a particular image failed.

Ah, I was just giving it as an example, I though you were disagreeing with me
with your first comment.

daniel added a comment.Via ConduitSep 26 2005, 7:58 PM

I agree that there should be an error message on the description page. Or, even
better, this should be detected on upload, and the image rejected.

bzimport added a comment.Via ConduitFeb 24 2009, 3:37 AM

codedread wrote:

Just to confirm:

  1. data: URLs _ARE_ allowed and supported in the svg image uploads + rasterization to PNGs that happen on wikimedia?
  1. do you scrub data: URLs to ensure that someone hasn't injected another SVG image (with potentially malicious script)?

If the answer is yes to both the above questions, then a potential solution is to update Inkscape so that upon importing a raster image, the user is presented with 3 options: a) embed raster as base64 data:, b) reference local file, c) reference a foreign URL - with sufficient explanations for these three options that a newbie can understand (i.e. "choose option a if you are uploading this file to wikipedia or openclipart")

If I get some feedback here I can open a bug and help push it along for Inkscape (if it hasn't been opened already - if there is an open bug, please link to it here).

Jeff Schiller

bzimport added a comment.Via ConduitApr 25 2009, 8:56 PM

codedread wrote:

FYI, I have finally opened <a href="">Bug 366993</a> against Inkscape for this issue.

brion added a comment.Via ConduitAug 3 2009, 4:53 PM

Assigning SVG bugs to Ariel -- need a cleanup pass to see what's fixed up by a librsvg upgrade, what can be resolved with fixes to our font configuration, what can be fixed on our end, and what still needs to be pushed upstream.

ArielGlenn added a comment.Via ConduitAug 6 2009, 9:01 PM

Say, I can't actually look at the launchpad bug to see what's up, it's marked private... Jeff, can you do anything about that?

brion added a comment.Via ConduitAug 6 2009, 9:06 PM

Data URIs _should_ currently work fine; at the moment we implement the restriction against external images by patching librsvg so it literally can't load external resources.

To generalize it via an upload-time check we would indeed want to be able to decode sub-SVG images to check for additional external resources in them; that's a detail I hadn't thought of earlier. :) Still shouldn't be absurdly hard to implement. I'm adding bug 7645 "Validate SVG content" as a dep for this...

And yes, would be very happy if Inkscape would start defaulting to embedding rasters when you add them!

bzimport added a comment.Via ConduitMay 17 2010, 1:40 PM

M8R-udfkkf wrote:

Although the <image> element is disabled for thumbnailing, if the user clicks on the thumbnail to enlarge the image, or is given a link to an image, the <image> element is still present.

As SVG's are rendered in firefox, an image with a "xlink:href" to a malicious image file would still go through. Or at least the user's IP would be revealed.

As an example, see!Kyokuryu-kai.svg in which you can see the google logo in the background. This is done by adding

   id="image2888" />

All SVGs with "xlink:href" should be marked with some type of warning, or the "xlink:href" stripped or commented out.

TheDJ added a comment.Via ConduitNov 4 2010, 1:10 AM

There is now an SVGParser in SVGMetadataExtractor.

I guess we could switch the SVG upload filter to this new mediahandler filter and have it look for xlink:href uri's. We could then warn when a file should not be uploaded. It's not hard to do I guess..

ArielGlenn added a comment.Via ConduitSep 18 2011, 9:13 AM

giving SVG bugs back to the pool.

brion added a comment.Via ConduitSep 19 2013, 3:15 PM

Switching to Wikimedia/SVG Rendering component.

Perhelion added a comment.Via ConduitOct 15 2014, 8:41 AM

Currently the image-tag get stripped, which made the SVG useless (upload). So I recommend to made a big warning (as reported on Commons: VP).

Add Comment