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:
How can we improve the web to make stuff like this more secure? Just setting up CSP (which can prevent the CSS issue) can be trial & error pain that is hard to test.
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.
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.
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.
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.
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.
> 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.
Sadly 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.
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.
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
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 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.
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.
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.
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.
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.
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).
If you are using something like Netlify, then you would need them to serve your S3 content from their CDN (which I don't think they support). For my specific use case, we host our application on our own domain (on our PaaS), then use a CDN for static assets. If we needed to also serve s3 assets from the same domain then it would mean routing routes in that node application to serve from s3 (effectively a server side proxy).
43 comments
[ 3.0 ms ] story [ 89.4 ms ] threadWith 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.
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.
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.
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
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.
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.
Otherwise its no different then doing curl on the attacker's machine.
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.
Securing your services regardless of where they are in the network should be go the go to
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.
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.
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.
Atlassian products are garbage for many reasons. But this is literally #1 for me. It's 100% unusable in a securified browser.
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).
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...
Something like a captcha or a security code maybe?
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.
Forcing same-site would require a server side proxy (defeating the point of using a CDN).