Follow up to Bug 1019925 In said bug, :asuth expressed concern with allowing SVG's as a type for data-URI images, so they were left out. Support needs to be built to look into the content of data-URI's to create proper whitelists for SVG security.
Please have somebody from security review it before landing.
If SVG is used in an image context i.e. via an <img> tag or as a background image then it's already secured. It can't load external data for instance and scripting is disabled. Isn't this enough?
Quoting asuth's comment inline here: (In reply to Andrew Sutherland (:asuth) from bug 1019925 comment #3) > :freddyb, for supporting data: URIs as inline images in emails, I'm > wondering/concerned about whether a nefarious email could be constructed > that uses a data URI to create an SVG doc which could then in turn reference > external images. (Thereby defeating our desire to require the user to > explicitly click to load any remote network resources and thereby leak the > fact that the email is being read.) As Robert says, as long as we're loading the SVG-data-URI in an <img> tag or as a CSS background, it will be prevented from loading any external resources. > Also a related question is whether the > data URI's awkward origin would let it escape our CSP rules and then run > some JS in there. SVG in an <img> / CSS background is also prevented from running script. (It can run SMIL animations, but not interactive ones.) If it's possible for the SVG data URI to be loaded in an <embed> or <object> or <iframe> element (or e.g. if the user can long-press it and choose "view directly" or something of the like), *then* there will be fewer restrictions on it. But as long as it's being displayed in an <img> or CSS background, you shouldn't have to worry about it hitting the network or running JS.
(For reference, bug 628747 is where we locked down access to external resources, for SVG as an image.)
That is great information, thank you to you both. It looks like bug 628747 only implements reftests. It sounds like there is no implementation work to be done, just add protective/paranoid unit tests.
You need to log in before you can comment on or make changes to this bug.