Closed Bug 628747 Opened 13 years ago Closed 13 years ago

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)

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b11

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

(Keywords: privacy)

Attachments

(2 files)

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.
(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)
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?
That's not good enough in the face of open redirectors on the forum in your comment 0 example, right?
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.
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)
Hardware: x86_64 → All
Summary: Consider imposing a same-domain restriction on all resource loads for SVG-as-an-image → SVG-as-an-image can load resources from other domains
OS: Linux → All
Attached patch fixSplinter Review
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.)
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Attachment #507208 - Flags: review?(bzbarsky)
(The test modification in comment 7 serves to test this bug, too, at least in part.)
Comment on attachment 507208 [details] [diff] [review]
fix

r=me.  Need to get this into a beta.
Attachment #507208 - Flags: review?(bzbarsky) → review+
Attachment #507208 - Flags: approval2.0?
Landed: http://hg.mozilla.org/mozilla-central/rev/0435ed183c2d
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
Depends on: 629448
Hmm. Couldn't we allow same-origin loads and just prevent redirects to other origins? Or prevent all redirects?
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.
That would actually be pretty difficult (e.g. doing it for images would be rocket science, I suspect).
No longer depends on: 629448
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(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"
(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.
...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.
Attachment #507692 - Flags: review?(bzbarsky)
Attachment #507692 - Flags: review?(roc)
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?
I wouldn't trust some open redirectors to not read the url from the filepath.  :(
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?
(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.
> I guess so -- at least, this builds successfully (both libxul & disable-libxul

That's all I really cared about here, yes.
Attachment #507692 - Flags: approval2.0?
Attachment #507692 - Flags: review?(bzbarsky) → review+
Attachment #507692 - Attachment description: fix v2, WIP: check URI_IS_LOCAL_RESOURCE, notify in error console, add tests → fix v2: check URI_IS_LOCAL_RESOURCE, notify in error console, add tests
Blocks: 629682
(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.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
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.
Sure - so those particular ones aren't the types of websites whose expectations I was worried about violating in comment 0.
Keywords: privacy
Summary: SVG-as-an-image can load resources from other domains → SVG-as-an-image shouldn't be able to load external resources (which might come from other domains)
Is there any plan to have another look at this issue?

External resources are pretty handy to have sometimes.
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
(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.
Blocks: 693940
Blocks: 739726
Depends on: 772443
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.
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?
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.
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.
Summary: SVG-as-an-image shouldn't be able to load external resources (which might come from other domains) → 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)
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.
> 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.
(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.
(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.
Depends on: 928790
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?
(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.
(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.
(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.
(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>
(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)
(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.)
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.
(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.)
(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.
> 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.
You need to log in before you can comment on or make changes to this bug.