Re: SVG image security restrictions

> On 16 Sep 2015, at 6:10 AM, Daniel Holbert <dholbert@mozilla.com> wrote:
> 
> On 09/14/2015 04:49 PM, Robert O'Callahan wrote:
>> I don't understand the minutes very well, but heycam says authors want
>> SVG images that can load external resources for sharing purposes, i.e.,
>> the "animated mode" from here:
>> https://svgwg.org/specs/integration/#animated-mode
>> 
>> We don't support that mode currently because it can lead to surprising,
>> privacy-harming behavior for Web sites that allow third-party image
>> uploads and have open redirectors. Example
> 
> Even without an open redirector, there are cases with
> surprising/undesirable behaviors. One example that I've thought about
> recently: sites that try to work around ad-blockers by serving 3rd-party
> ad banners from their own domain (via a server-side proxy).  If we grant
> same-origin-loading privileges to SVG images, then these ad banners
> could pull in arbitrary resources from the site that the user is
> visiting, e.g. to make the ad look more personalized.
> 
> Hypothetical scenario which demonstrates the problem:
> (1) Some site, say socialnetwork.com, serves banner-image ads provided
> by adserver.com.
> (2) A user of that site has an ad-blocker extension which blocks
> connections to adserver.com.
> (3) When that user visits socialnetwork.com, the site detects that the
> ad failed to load. It then updates the ad-banner <img> element to now
> point to a resource on socialnetwork.com (instead of adserver.com), and
> it transparently proxies that URI (server-side) to actually load a
> resource from the ad network.
> (4) Now the ad successfully loads (because the ad blocker allows
> resources from socialnetwork.com).  BUT: also, now the browser sees the
> ad image as being same-origin with socialnetwork.com.
> (5) An sneaky advertiser takes advantage of this by constructing an SVG
> ad-banner, which tries to reference the user's profile image (which
> let's say lives at a well-known URI like
> socialnetwork.com/currentUser/profile.jpg) as an <svg:image> inside of
> the ad.
> (6) So now, the user sees an ad-banner with their own photo *inside of
> the ad*.
> 
> If we allow SVG images to load same-origin resources, then this would
> totally work, and would be surprising to the social network site. They
> were presumably sweet-talked into allowing 3rd-party ads to be served
> via their own domain, as a way of getting around ad-blockers, because
> they bought into the reasonable assumption that (unlike e.g. scripts)
> images were self-contained things that had no special same-origin
> privileges.

Thanks for this description. I really hope we can find some way to
enable limited external resources in SVG.

I have a question though. Pretend you are talking to a security idiot
(which is pretty close to reality).

If a site like socialnetwork.com is willing to invisibly proxy requests
to adserver.com, then aren't they already opening the door for users
to see their profile pictures in ads? Are you expecting that socialnetwork.com
was somehow convinced by adserver.com that they'd only ever serve image
data? In nearly every case I've seen, the adserver gets the site to include
a script tag, which helps them better track whether the user saw the ad and/or
interacted with it. Moving to the model you describe above would mean a lot of
logic needs to happen in socialnetwork.com's content (did resources from
adserver load? No, then insert an <img> element, etc...). And this logic
would have to be reproduced in all sites who want to serve ads this way.
And it would be a pain to maintain.

Basically I'm asking if a site is willing to do invisible server-side proxying,
aren't there a lot of horrible things that could happen? It seems the
external resource from SVG isn't that horrible in comparison.

Dean

Received on Wednesday, 16 September 2015 00:52:15 UTC