Basically i dont think anyone should worry about this.
All website operators should read this imo: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_...
Everything is a target. You can’t assume safety based on reputation or ubiquitousness.
There are so many examples of the trusted well-used thing failing security to mention.
I've been able to make realistic attacks against multiple targets. Many services, such as Google Docs, need to enable cross-origin framing for their functionality.
And beyond that, even if you restrict the framing, it might still be possible to clickjack as a part of a more complex attack chain, see: https://lyra.horse/blog/2024/09/using-youtube-to-steal-your-...
And the attack in OP does not require iframes, so it can also be applied to injection attacks where CSP prevents javascript for example.
(disclaimer: author of story)
> it's usually the opposite with it being not even accepted by many bug bounty programs.
As someone who has been on the other end of bug bounty's, its because clickjacking reports are a massive spam magnet. 99% of reported are not really vulns (e.g. no xfo header on a static website with no user auth, is not a vuln), and its just not worth sorting through.
> I've been able to make realistic attacks against multiple targets. Many services, such as Google Docs, need to enable cross-origin framing for their functionality.
The google docs thing is really cool. However i think services that need authenticated frames are few and far between. Now that cookies on frames tend to be opt in, i think the number of vulnerable services is going to go way down. Its not going to be 0, but its going to be pretty limited.
A valid report needs to demonstrate a realistic attack scenario, and I think that's the approach bug bounties should take.
I think a good example is Google with its stance on open redirects[0]. They won't accept a report just pointing one out, but they will accept one that "can demonstrate that its impact goes beyond phishing".
[0] https://bughunters.google.com/learn/invalid-reports/web-plat...
What specifically does Google Docs do that requires it?
> And the attack in OP does not require iframes
How do you frame the victim site without iframes?
Google wants documents to be embeddable on external sites.
> How do you frame the victim site without iframes?
You don't, you use it in a different scenario. For example if you have HTML injection, but its fairly limited due to strict CSP.
Researchers have observed that, in Chrome:
A hostile webpage can create SVG or CSS filters that cover an iframe on the same page and act on the iframe's content.
Specially-crafted filters can be created that vary their performance characteristics (different use of memory bandwidth or compute resources) based on input data.
The induced differences in load can, in turn, be used to leak the input data through a timing sidechannel readable from Javascript.