Last Comment Bug 628747 - SVG-as-an-image shouldn't be able to load external resources (which might come from other domains) (including same-origin resources, which could be using an open redirector)
: SVG-as-an-image shouldn't be able to load external resources (which might com...
Status: RESOLVED FIXED
: privacy
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla2.0b11
Assigned To: Daniel Holbert [:dholbert]
:
: Jet Villegas (:jet)
Mentors:
: 629448 (view as bug list)
Depends on: 772443 928790
Blocks: 629682 693940 739726
  Show dependency treegraph
 
Reported: 2011-01-25 11:55 PST by Daniel Holbert [:dholbert]
Modified: 2015-10-21 10:49 PDT (History)
17 users (show)
dholbert: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (3.78 KB, patch)
2011-01-26 12:39 PST, Daniel Holbert [:dholbert]
bzbarsky: review+
roc: approval2.0+
Details | Diff | Splinter Review
fix v2: check URI_IS_LOCAL_RESOURCE, notify in error console, add tests (8.13 KB, patch)
2011-01-27 15:45 PST, Daniel Holbert [:dholbert]
bzbarsky: review+
roc: review+
roc: approval2.0+
Details | Diff | Splinter Review

Description Daniel Holbert [:dholbert] 2011-01-25 11:55:20 PST
SVG has a few types of resources that could be loaded from remote domains:
 - <svg:image>
 - stylesheets
 - scripts
  (anything else?)

This allows for some potentially undesirable use-cases for SVG-as-an-image.

Consider a hypothetical forum that allows SVG images as avatars. Right now, a trickster/malicious user could upload an SVG file that contains
 <image xlink:href="http://evilhacker.com/myimage.png">
and (assuming they control evilhacker.com), they could do any & all of the following:
 - receive a ping at their own domain whenever anyone views their profile (& log the ip address of the person viewing it)
 - potentially serve different-looking avatar to different people based their IP address, request-headers, etc.
 - potentially change the appearance of their avatar at-will (i.e. wait for forum-admins to approve it thumbs-up, and then change it to be NSFW)

Opera 11.00 behaves like we do in this respect (they're susceptible to this issue).  In contrast, Chromium (9.0.597.67) completely disables <image> inside of SVG-as-an-image.  (not sure whether that's because of this issue or just to avoid problems with image-recursion)

Seems like we might want to take a middle-ground and allow resources from the same domain, but not from other domains.
Comment 1 Daniel Holbert [:dholbert] 2011-01-25 12:05:01 PST
(In reply to comment #0)
> SVG has a few types of resources that could be loaded from remote domains:
>  - scripts

(note that scripts won't be executed in svg-as-an-image, but they might (?) still get downloaded and could act as a pingback to an arbitrary remote domain)
Comment 2 Daniel Holbert [:dholbert] 2011-01-25 12:12:28 PST
So I imagine there's a place (or places) in resource-loading code where we could just add some code like:
 if (myDoc->IsBeingUsedAsImage() &&
     myDoc->[domain] != resourceURI->[domain]) {
      // return a failure code, triggering the same type of cross-domain
      // security notification as when we fail to load a remote SVG filter
    }
  }

bz: is this just as easy as that^, and do you know where it'd make sense to put that code?
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-01-25 12:16:02 PST
That's not good enough in the face of open redirectors on the forum in your comment 0 example, right?
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-25 12:32:11 PST
I guess the conservative thing to do is to block all loads from SVG images then :-(. Maybe we should do that for FF4 and raise the issue in the SVG WG?

We could say "don't host untrusted SVG images on your site if you have open redirectors", but that adds platform complexity. Maybe we should have a special MIME type for "trusted" SVG images.
Comment 5 Daniel Holbert [:dholbert] 2011-01-25 12:51:09 PST
Ah, I hadn't considered open redirectors... drat.  I think I agree with the beginning of comment 4 then.
(updating bug summary to more clearly state the general problem)
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-01-25 13:05:49 PST
Doing comment 4 is easy.  See the code around http://hg.mozilla.org/mozilla-central/file/6a097e294828/content/base/src/nsDataDocumentContentPolicy.cpp#l87
Comment 7 Daniel Holbert [:dholbert] 2011-01-26 12:39:12 PST
Created attachment 507208 [details] [diff] [review]
fix

This patch blocks all loads from SVG images, per comment 4.

This includes an tweak to the reference of one reftest that has an <img src="foo.svg"> w/ foo.svg including <image> elements.  (With the code change in this patch, those <image> elements are no longer rendered -- so I just disabled the relevant chunk of the reference case.)
Comment 8 Daniel Holbert [:dholbert] 2011-01-26 12:40:16 PST
(The test modification in comment 7 serves to test this bug, too, at least in part.)
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-01-26 12:50:35 PST
Comment on attachment 507208 [details] [diff] [review]
fix

r=me.  Need to get this into a beta.
Comment 10 Daniel Holbert [:dholbert] 2011-01-26 22:25:03 PST
Landed: http://hg.mozilla.org/mozilla-central/rev/0435ed183c2d
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-27 14:22:07 PST
Hmm. Couldn't we allow same-origin loads and just prevent redirects to other origins? Or prevent all redirects?
Comment 12 Daniel Holbert [:dholbert] 2011-01-27 14:30:01 PST
If that's something that's doable without too much hackery, I agree it'd be desirable...

(I also filed bug 629448 on allowing data:URIs -- but particularly if we refine this behavior along the lines of Comment 11, then I'll probably cancel that bug, back out comment 10, and land a better fix on this bug here.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2011-01-27 14:34:08 PST
That would actually be pretty difficult (e.g. doing it for images would be rocket science, I suspect).
Comment 14 Daniel Holbert [:dholbert] 2011-01-27 15:35:13 PST
*** Bug 629448 has been marked as a duplicate of this bug. ***
Comment 15 Daniel Holbert [:dholbert] 2011-01-27 15:38:06 PST
(I've duped bug 629448 to this bug and am going to address that bug's concerns here, since the first part of bug 629448 was going to be a backout of this bug's fix from Comment 10 anyway.)

I intend to back this out and land the updated patch back-to-back, maybe in the same push.
Comment 16 Daniel Holbert [:dholbert] 2011-01-27 15:45:24 PST
Created attachment 507692 [details] [diff] [review]
fix v2: check URI_IS_LOCAL_RESOURCE, notify in error console, add tests

This is a mostly-done better fix -- it now allows uris that pass the URI_IS_LOCAL_RESOURCE test (data URIs are ok, and local-files-loading-local-files are OK -- neither of those leak data via the network).

This also adds error-console notifications, so that authors get a hint about what's going wrong when their SVG images run afoul of this new check.

Caveats:
 (a) I'm using "CheckSameOriginError" for the error-console notification, but technically this isn't necessarily a same origin (though different-origin issues are what we're really trying to prevent, with a hammer that squashes some same origin cases as well).
 (b) Right now we post 2 copies of the error to the console for some reason, for each load / shift+reload that triggers a dropped resource-load.  Need to look into that - maybe we're getting 2 calls to nsDataDocumentContentPolicy::ShouldLoad for the same resource for some reason?

I'm not super-worried about (a), because we use that error-message somewhat liberally already (e.g. when we block local files from loading SVG filters from another local file in a different directory), and we probably don't want to add a custom string for this case after the string-freeze.
Comment 17 Daniel Holbert [:dholbert] 2011-01-27 15:47:31 PST
(In reply to comment #16)
> Caveats:
>  (a) I'm using "CheckSameOriginError" for the error-console notification, but
> technically this isn't necessarily a same origin 

er, I meant "technically the blocked content isn't necessarily from a different origin"
Comment 18 Daniel Holbert [:dholbert] 2011-01-27 16:10:58 PST
(In reply to comment #16)
>  (b) Right now we post 2 copies of the error to the console for some reason,
> for each load / shift+reload that triggers a dropped resource-load.  Need to
> look into that - maybe we're getting 2 calls to
> nsDataDocumentContentPolicy::ShouldLoad for the same resource for some reason?

Ok -- so we're actually getting two separate calls to nsSVGImageElement::LoadSVGImage for the blocked <svg:image> element -- the first in nsSVGImageElement::AfterSetAttr for the "xlink:href" attr, and the second inside "MaybeLoadSVGImage" which is enqueued in a Runnable inside of nsSVGImageElement::BindToTree().

As long as we've got those two separate calls, it seems reasonable (albeit a little strange from an author's perspective) to post two entries in the error console.  Better to report an extra error than to report none at all.
Comment 19 Daniel Holbert [:dholbert] 2011-01-27 16:14:13 PST
...and for other resources like stylesheets, we only post one error (good).  So (b) from comment 16 is just a quirk of our <svg:image> implementation.
Comment 20 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-27 17:18:48 PST
I've got another idea: what if we blocked loads with HTTP query parameters? Would that be enough to address the open redirector problem? Too hacky?
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2011-01-27 18:05:42 PST
I wouldn't trust some open redirectors to not read the url from the filepath.  :(
Comment 22 Boris Zbarsky [:bz] (still a bit busy) 2011-01-27 18:10:08 PST
Is caps linked into gklayout nowadays?

And do we want to file a bug on a better error message here once we're not in l10n freeze?
Comment 23 Daniel Holbert [:dholbert] 2011-01-27 20:52:42 PST
(In reply to comment #22)
> Is caps linked into gklayout nowadays?

I guess so -- at least, this builds successfully (both libxul & disable-libxul -- I tried both :)).

> And do we want to file a bug on a better error message here once we're not in
> l10n freeze?

Yeah, I'll file that before closing this.
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2011-01-27 21:05:56 PST
> I guess so -- at least, this builds successfully (both libxul & disable-libxul

That's all I really cared about here, yes.
Comment 25 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-01-28 06:44:00 PST
Yes, caps is in gklayout.
Comment 26 Daniel Holbert [:dholbert] 2011-01-28 08:07:44 PST
Backed out first patch: http://hg.mozilla.org/mozilla-central/rev/9332128cc437
and landed patch v2:    http://hg.mozilla.org/mozilla-central/rev/21f96c423923
Comment 27 Daniel Holbert [:dholbert] 2011-01-28 08:18:13 PST
(In reply to comment #23)
> > And do we want to file a bug on a better error message here once we're not in
> > l10n freeze?
> 
> Yeah, I'll file that before closing this.

Filed bug 629682.
Comment 28 Daniel Cater 2011-01-29 09:30:22 PST
Note that quite a few forums let users use a remote image as their avatar, in which case the user can already do all of the things mentioned in comment 0.
Comment 29 Daniel Holbert [:dholbert] 2011-01-29 11:05:06 PST
Sure - so those particular ones aren't the types of websites whose expectations I was worried about violating in comment 0.
Comment 30 Douglas Miller 2011-07-05 06:44:51 PDT
Is there any plan to have another look at this issue?

External resources are pretty handy to have sometimes.
Comment 31 Daniel Holbert [:dholbert] 2011-09-09 15:24:54 PDT
Nope, no plan to re-evaluate this at this point.

(If we were to re-evaluate this, we'd need a strategy for preventing the sorts of attacks / privacy-leakages brought up in comment 0, and it'd probably need to account for open redirectors as brought up in comment 3)

If you need external resources like e.g. external graphics, you can encode them as data URIs by uploading them at the data URI kitchen[1], and then embed them directly in the document.  (For example, view the source of the testcase[2] checked in with this bug's patch.)

[1] http://software.hixie.ch/utilities/cgi/data/data
[2] https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/svg/as-image/svg-image-datauri.svg
Comment 32 Douglas Miller 2011-09-10 18:25:54 PDT
(In reply to Daniel Holbert [:dholbert] (vacation 9/17-9/24) from comment #31)
> If you need external resources like e.g. external graphics, you can encode
> them as data URIs by uploading them at the data URI kitchen

Alright sounds fine. Thanks for responding.
Comment 33 Philip Rogers 2012-08-09 20:26:03 PDT
Could this scheme be relaxed by allowing external resources if the svg file itself is loaded via a data uri? This would allow a user to convert a local svg document into an image for canvas.context2d.drawImage() while maintaining the cacheability and memory advantages of external resources over data uris.
Comment 34 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-08-09 20:44:00 PDT
That would require very careful security analysis. Even if we can prove it's safe today, it would impose constraints on the evolution of the Web that we probably would rather not deal with.

We do allow data: URIs to reference blob URIs, and you can just convert a local SVG document to a blob and avoid data: URIs altogether. Does that help you?
Comment 35 Estelle Weyl 2013-04-22 15:11:51 PDT
They SHOULD, however, be able to load resources that come from the same domain. That is currently blocked.

test case: http://www.standardista.com/clowncar/clownbackgroundsize.html

The SVG file it calls is located at http://www.standardista.com/clowncar/clown.svg. This SVG works fine, calling in images relative to the SVG. When the SVG is called via <img>, the assets the SVG is trying to request are blocked. If they weren't blocked, the clown car technique (http://github.com/estelle/clowncar/) would be a good solution to responsive images.

The images are same domain, so am unclear what the security risk is that has resulted in their blockage.
Comment 36 Daniel Holbert [:dholbert] 2013-04-22 15:41:25 PDT
That will still be unsafe in cases where your domain has an open redirector, as noted in comment 3.

e.g. suppose http://getpocket.com started a forum and let users upload unsanitized SVG images as their forum avatars. Since getpocket.com has an open redirector (at http://getpocket.com/redirect ), this would expose them to the sneaky attacks described in comment 0 -- users could just pull in e.g. http://getpocket.com/redirect?url=http://example.com where example.com could be any remote resource, but would appear as a same-origin resource.

(I'll edit the bug-summary to clarify this.)

To prevent this, we decided to basically close off all external resources, including apparently-same-origin ones, with the exception of ones that are treated as "local" to the file, in that they don't hit the network. (data URIs and blob URIs fall into this category)  If you need an external resource, encode it as a data URI or a blob URI.
Comment 37 Dirk Schulze 2013-05-29 13:28:34 PDT
I wonder if there isn't the same problem with external resources like SVG filters and SVG masks.

I had this in a separate file img.svg:

    <filter id="filter">
        <feImage xlink:href="img.jpg" width="100" height="100"/>
    </filter>

And referenced this file with the following code in an HTML file:

    filter: url(img.svg#filter);

If you try that, you'll see that the image gets loaded and displayed. This image load however should have the same security concerns on open redirects like a normal SVG image with external resources.
Shouldn't external resources (like masks and filters) be restricted not to load any resources as well for the same reasons as for SVG images? If so, I am happy to open a separate bug with a test case.
Comment 38 Daniel Holbert [:dholbert] 2013-05-29 13:42:13 PDT
> Shouldn't external resources (like masks and filters) be restricted not
> to load any resources as well for the same reasons as for SVG images?

Not for "the same reasons", no.

The main reason behind *this* bug is that web authors *already have* a security model in their head for how images behave[1] developed from their experience with raster-images -- and if they allow users to e.g. upload SVG-image avatars (as we'd like them to be able to), we don't want that to be a security footgun.

[1] In particular, an image shouldn't trigger any network connections (privacy concern), and an image's rendering shouldn't be able to be modified on the fly via tweaks to an external piece of content (surprise-NSFW-avatar concern)

Authors don't have as much experience with filters, so there's no reason to assume they have the same instinctual assumptions (or any assumptions) about filter capabilities. There are also much fewer scenarios where an author would allow users to display a user-controlled filter on the author's own site. (as opposed to images, where that's common for galleries/avatars/etc)  

So: There may be reasons to change behavior of filters (I don't know), but they're probably not "the same reasons" as on this bug, and they deserve their own bug.
Comment 39 Dirk Schulze 2013-05-29 13:52:28 PDT
(In reply to Daniel Holbert [:dholbert] from comment #38)
> > Shouldn't external resources (like masks and filters) be restricted not
> > to load any resources as well for the same reasons as for SVG images?
> 
> Not for "the same reasons", no.
> 
> The main reason behind *this* bug is that web authors *already have* a
> security model in their head for how images behave[1] developed from their
> experience with raster-images -- and if they allow users to e.g. upload
> SVG-image avatars (as we'd like them to be able to), we don't want that to
> be a security footgun.
> 
> [1] In particular, an image shouldn't trigger any network connections
> (privacy concern), and an image's rendering shouldn't be able to be modified
> on the fly via tweaks to an external piece of content (surprise-NSFW-avatar
> concern)
> 
> Authors don't have as much experience with filters, so there's no reason to
> assume they have the same instinctual assumptions (or any assumptions) about
> filter capabilities. There are also much fewer scenarios where an author
> would allow users to display a user-controlled filter on the author's own
> site. (as opposed to images, where that's common for galleries/avatars/etc)  
> 
> So: There may be reasons to change behavior of filters (I don't know), but
> they're probably not "the same reasons" as on this bug, and they deserve
> their own bug.

With "the same reason" I didn't refer to your specific use case, but to the privacy concern itself. It can still be used for a tracking site loads, even if the steps to make that happen are a lot more difficult (the SVG resource must be CORS conform for Firefox).

If you reference an SVG resource from a different server, then this server could still be compromised and track the access of the resources used on your site and ultimately have assumptions about the number of page loads.
Comment 40 Daniel Holbert [:dholbert] 2013-05-29 14:06:16 PDT
(In reply to Dirk Schulze from comment #39)
> It can still be used for a tracking site loads, even
> if the steps to make that happen are a lot more difficult (the SVG resource
> must be CORS conform for Firefox).
> 
> If you reference an SVG resource from a different server, then this server
> could still be compromised and track the access of the resources used on
> your site and ultimately have assumptions about the number of page loads.

Sure. The same is true if you have <img src="http://example.com/image.jpg">

That in and of itself isn't the issue.

The distinction is that authors assume it's safe to embed **user-uploaded** images on their sites. They don't make those same assumptions about filters (or about scripts, or about stylesheets), so the security/capability situation is different there.
Comment 41 mmis1000 2013-11-07 09:21:16 PST
well... I really don't think a svg as a tracker is a problem.
if <img src="http://example.com/image.jpg"> is allowed to use in a website,
then it can actually track the page and do every thing (change it to what you want like random image and etc...) what you want.
Lots of website use a uncacheable 1*1 image to trace its visits(since the cache issue can stop browser from sent http request to the broser)
Indeed, I tried that before by use a php page and .htaccess.
Use URL Rewriting, you can make any dynamic page has a url like a static resource.
Image element is useless without external resource access I thought(probably make a access control file like flash?).
Btw, is it possible to use base64 coding to embed pixel image in svg?
Comment 42 Daniel Holbert [:dholbert] 2013-11-07 10:15:35 PST
(In reply to mmis1000 from comment #41)
> well... I really don't think a svg as a tracker is a problem.
> if <img src="http://example.com/image.jpg"> is allowed to use in a website,
> then it can actually track the page and do every thing (change it to what
> you want like random image and etc...) what you want.

That's a different use-case than the use cases we're concerned with here. Please read Comment 40, which addresses exactly this point.

> Btw, is it possible to use base64 coding to embed pixel image in svg?

Yes; you can upload a file to http://software.hixie.ch/utilities/cgi/data/data and produce a data URI from it, and you're definitely able to include *that* in SVG images, per end of comment 36.
Comment 43 Salek Talangi 2015-03-22 04:46:09 PDT
(In reply to Daniel Holbert [:dholbert] from comment #0)
> SVG has a few types of resources that could be loaded from remote domains:
>  - <svg:image>
>  - stylesheets
>  - scripts

While I completely get why this bug report was opened and amended by the even-not-same-origin-part, the initial behavior was there for a reason, too.
Wouldn't it be possible to find a way to get the best from both worlds, security from not loading external resources by default and the comfort of styled SVGs?

How about some GET query parameter? Forum/Page owners could implement a "?load_ext_res=true" for img-srcs they output when they want to use the feature, because they either have sanitized the uploaded SVG or don't allow SVGs to be uploaded or any upload at all.

It's a pity that with the current way things are we'll never get externally styled SVG.
Comment 44 Daniel Holbert [:dholbert] 2015-03-22 10:24:14 PDT
(In reply to Salek Talangi from comment #43)
> While I completely get why this bug report was opened and amended by the
> even-not-same-origin-part, the initial behavior was there for a reason, too.

Nope -- as the person who implemented our SVG-as-an-image behavior, I can tell you that it was *not* there for any good reason. :) (I simply hadn't thought about the scenario in comment 0 at the time & hadn't realized it was problematic & needing to be locked down.)

> Wouldn't it be possible to find a way to get the best from both worlds,
> security from not loading external resources by default and the comfort of
> styled SVGs?

Maybe?  I think it'd have to be an opt-in thing (so that by default, people can expect user-provided SVGs to be locked down).

Note that right now, the SVG Integration spec specifically calls for our current behavior:
  http://www.w3.org/TR/svg-integration/#secure-animated-mode

I don't think this is likely to change.  But if you'd like to propose something or raise concerns, the best place is probably on the SVG Working Group mailing list, at www-svg@w3.org -- not here at in comment 40+ on this long-closed bug.

> It's a pity that with the current way things are we'll never get externally
> styled SVG.

Note that you can still use external resources for SVG in <iframe>, <embed>, <object>, and in inline SVG tags directly-in-an-HTML-document.  The only place you can't is when it's being used as an image.  You might reconsider if you can use one of those other strategies to achieve what you're going for.
Comment 45 ytrezq 2015-08-13 10:23:31 PDT
(In reply to Daniel Holbert [:dholbert] from comment #44)
> Note that you can still use external resources for SVG in <iframe>, <embed>,
> <object>, and in inline SVG tags directly-in-an-HTML-document.  The only
> place you can't is when it's being used as an image.
No this is no longer true as using foreignObject in svg used as image is no longer allowed.
sample file that can be included from an html page :

<?xml version="1.0" ?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Script" width="100%" height="1000px" onLoad="alert('hello world!')" preserveAspectRatio="none">
        <defs>
                <style type="text/css"><![CDATA[
                        svg
                        {
                                background-image: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiA/Pgo8c3ZnIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgb25Mb2FkPSJhbGVydCgnaGVsbG8gd29ybGQhJykiIHZpZXdCb3g9IjAgMCAxIDEiIHByZXNlcnZlQXNwZWN0UmF0aW89Im5vbmUiPgogIDxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij48IVtDREFUQVsKICAgIGFsZXJ0KCJoZWxsbyB3b3JsZCEiKTsKICBdXT48L3NjcmlwdD4KICA8bGluZWFyR3JhZGllbnQgaWQ9ImdyYWQtdWNnZy1nZW5lcmF0ZWQiIGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIiB4MT0iMCUiIHkxPSIxMDAlIiB4Mj0iMTYlIiB5Mj0iMCUiPgogICAgPHN0b3Agb2Zmc2V0PSIwJSIgc3RvcC1jb2xvcj0iI2YwZjhmZiIgc3RvcC1vcGFjaXR5PSIxIi8+CiAgICA8c3RvcCBvZmZzZXQ9IjQlIiBzdG9wLWNvbG9yPSIjZmFmZGZmIiBzdG9wLW9wYWNpdHk9IjEiLz4KICAgIDxzdG9wIG9mZnNldD0iNyUiIHN0b3AtY29sb3I9IiNmZmZmZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSIzNCUiIHN0b3AtY29sb3I9IiNmZmZmZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI0MCUiIHN0b3AtY29sb3I9IiNmMmY4ZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI0NCUiIHN0b3AtY29sb3I9IiNlZGY2ZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI1MCUiIHN0b3AtY29sb3I9IiNlMGYwZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI1NiUiIHN0b3AtY29sb3I9IiNkM2VhZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI2MCUiIHN0b3AtY29sb3I9IiNjOWU1ZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI2NSUiIHN0b3AtY29sb3I9IiNiN2RjZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI2OSUiIHN0b3AtY29sb3I9IiNhZGQ3ZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI3MiUiIHN0b3AtY29sb3I9IiNhM2QyZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI4NyUiIHN0b3AtY29sb3I9IiM2ZGI0ZjIiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI5NiUiIHN0b3AtY29sb3I9IiMzMjljZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSI5OCUiIHN0b3AtY29sb3I9IiMxOTkwZmYiIHN0b3Atb3BhY2l0eT0iMSIvPgogICAgPHN0b3Agb2Zmc2V0PSIxMDAlIiBzdG9wLWNvbG9yPSIjMDA4M2ZmIiBzdG9wLW9wYWNpdHk9IjEiLz4KICA8L2xpbmVhckdyYWRpZW50PgogIDxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij48IVtDREFUQVsKICAgIGFsZXJ0KCJoZWxsbyB3b3JsZCEiKTsKICBdXT48L3NjcmlwdD4KICA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBmaWxsPSJ1cmwoI2dyYWQtdWNnZy1nZW5lcmF0ZWQpIiAvPgogIDxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij48IVtDREFUQVsKICAgIGFsZXJ0KCJoZWxsbyB3b3JsZCEiKTsKICBdXT48L3NjcmlwdD4KPC9zdmc+Cg==); /* this works */
                        }
                ]]></style>
        </defs>
        <foreignObject width="100%" height="100%" opacity="1">
                <html xmlns="http://www.w3.org/1999/xhtml">
		<head>
		    <title>sample image to be included in an html page</title>
		</head>
		<body>
		    <h1>Found !</h1>
		    <p>The requested URL /fghjkl was found on this server.</p>
		</body>
		</html>
		<iframe xmlns="http://www.w3.org/1999/xhtml" src="data:text/html;base64,PCFkb2N0eXBlIGh0bWw+CjxodG1sPgo8aGVhZD4KICAgIDx0aXRsZT5FeGFtcGxlIERvbWFpbjwvdGl0bGU+CgogICAgPG1ldGEgY2hhcnNldD0idXRmLTgiIC8+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIgLz4KICAgIDxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lkdGgsIGluaXRpYWwtc2NhbGU9MSIgLz4KICAgIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+CiAgICBib2R5IHsKICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZjBmMGYyOwogICAgICAgIG1hcmdpbjogMDsKICAgICAgICBwYWRkaW5nOiAwOwogICAgICAgIGZvbnQtZmFtaWx5OiAiT3BlbiBTYW5zIiwgIkhlbHZldGljYSBOZXVlIiwgSGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZjsKICAgICAgICAKICAgIH0KICAgIGRpdiB7CiAgICAgICAgd2lkdGg6IDYwMHB4OwogICAgICAgIG1hcmdpbjogNWVtIGF1dG87CiAgICAgICAgcGFkZGluZzogNTBweDsKICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmOwogICAgICAgIGJvcmRlci1yYWRpdXM6IDFlbTsKICAgIH0KICAgIGE6bGluaywgYTp2aXNpdGVkIHsKICAgICAgICBjb2xvcjogIzM4NDg4ZjsKICAgICAgICB0ZXh0LWRlY29yYXRpb246IG5vbmU7CiAgICB9CiAgICBAbWVkaWEgKG1heC13aWR0aDogNzAwcHgpIHsKICAgICAgICBib2R5IHsKICAgICAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogI2ZmZjsKICAgICAgICB9CiAgICAgICAgZGl2IHsKICAgICAgICAgICAgd2lkdGg6IGF1dG87CiAgICAgICAgICAgIG1hcmdpbjogMCBhdXRvOwogICAgICAgICAgICBib3JkZXItcmFkaXVzOiAwOwogICAgICAgICAgICBwYWRkaW5nOiAxZW07CiAgICAgICAgfQogICAgfQogICAgPC9zdHlsZT4gICAgCjwvaGVhZD4KCjxib2R5Pgo8ZGl2PgogICAgPGgxPkV4YW1wbGUgRG9tYWluPC9oMT4KICAgIDxwPlRoaXMgZG9tYWluIGlzIGVzdGFibGlzaGVkIHRvIGJlIHVzZWQgZm9yIGlsbHVzdHJhdGl2ZSBleGFtcGxlcyBpbiBkb2N1bWVudHMuIFlvdSBtYXkgdXNlIHRoaXMKICAgIGRvbWFpbiBpbiBleGFtcGxlcyB3aXRob3V0IHByaW9yIGNvb3JkaW5hdGlvbiBvciBhc2tpbmcgZm9yIHBlcm1pc3Npb24uPC9wPgogICAgPHA+PGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9kb21haW5zL2V4YW1wbGUiPk1vcmUgaW5mb3JtYXRpb24uLi48L2E+PC9wPgo8L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+Cg=="></iframe><!-- doesn’t works even in that case with a data ᴜʀɪ −−>
	</foreignObject>
</svg>
Comment 46 Daniel Holbert [:dholbert] 2015-08-13 11:06:46 PDT
(In reply to ytrezq from comment #45)
> (In reply to Daniel Holbert [:dholbert] from comment #44)
> > Note that you can still use external resources for SVG in <iframe>, <embed>,
> > <object>, and in inline SVG tags directly-in-an-HTML-document.  The only
> > place you can't is when it's being used as an image.
> No this is no longer true as using foreignObject in svg used as image is no
> longer allowed.

I think you misunderstood me.

It sounds like you read me as saying "You can use <iframe>, etc. inside of an SVG-as-an-image to pull in external resources".  But really, I was saying "You can still reference external things from SVG if you include the SVG via <iframe>, etc."

Having said that -- you're right that we block <iframe src="data URI"> inside of SVG-as-an-image, though that's unrelated to this bug. That's intentional, to prevent authors from being able to test whether links are visited by rendering them in iframes inside of SVG.  That change happened in bug 656448, partly in response to http://robert.ocallahan.org/2011/11/drawing-dom-content-to-canvas.html?showComment=1320734103970#c4021554625723456207

If you have concerns about this, please file a new bug and CC me (or find me in IRC, or post to dev.platform), rather than continuing this conversation on this bug here.  It's tangential to the main issues discussed in this bug, and this bug is already fairly long & hard to follow. (and discussing new side issues will make it impossible to follow)
Comment 47 Daniel Holbert [:dholbert] 2015-08-13 11:11:55 PDT
(In reply to Daniel Holbert [:dholbert] from comment #46)
> Having said that -- you're right that we block <iframe src="data URI">
> inside of SVG-as-an-image, though that's unrelated to this bug. [...]
> That change happened in bug 656448

Gah, sorry, mis-paste -- I meant bug 700895.

(The attack scenario here is someone drawing an SVG image to a canvas, and seeing whether links in the SVG image are styled as visited. We already foil this for the image document itself, via bug 641731, but the <iframe> would create its own separate non-image document [with scripting disabled], so bug 641731 doesn't help us there. So as a safety measure, we simply prevent subdocuments entirely in SVG-as-an-image.)
Comment 48 ytrezq 2015-08-13 11:54:32 PDT
never mind https://bugzilla.mozilla.org/show_bug.cgi?id=1194373.

But even without requiredFeatures="http://www.w3.org/TR/SVG11/feature#Script" iframes will never loads. Which seems perfectly legit for me.
Comment 49 Daniel Holbert [:dholbert] 2015-08-13 12:00:24 PDT
(In reply to ytrezq from comment #48)
> But even without
> requiredFeatures="http://www.w3.org/TR/SVG11/feature#Script" iframes will
> never loads. Which seems perfectly legit for me.

(Right -- the iframe won't load in SVG-as-an-image, as explained after "Having said that" in comment 46 / 47.)
Comment 50 IllidanS4 2015-10-21 10:37:15 PDT
(In reply to Daniel Holbert [:dholbert] from comment #0)
> Consider a hypothetical forum that allows SVG images as avatars.
Surely forum security is a matter of the browser and not the forum programmer.
Comment 51 Boris Zbarsky [:bz] (still a bit busy) 2015-10-21 10:49:59 PDT
> Surely forum security is a matter of the browser

It's a matter for both.  A forum programmer should make sure that there are no security holes.  Then browsers should not add features that cause previously secure code to be insecure.

Note You need to log in before you can comment on or make changes to this bug.