Comment by bawolff
2 months ago
That's cool and all, but clickjacking is really overrated and its easy to address via x-frame-options. Most attack scenarios are very convoluted and impractical in real life (doubly so now that samesite cookies and cookie storage partitioning is now a thing).
Basically i dont think anyone should worry about this.
You're right that everyone should be using X-Frame-Options: DENY (for ancient browsers, plus CSP for newer browsers), but the author managed to pull it off on Google Docs. If even Google can't consistently stick to it, I feel like I should be worried.
All website operators should read this imo: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_...
> If even Google can't consistently stick to it
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 don't think clickjacking is overrated, it's usually the opposite with it being not even accepted by many bug bounty programs.
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)
I hope im not coming off dismissive, this really is cool research.
> 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.
I don't think invalid spam reports mean something is overrated. Spam reports are spam reports. That'd be like saying buffer overflows are overrated because there are a bunch of AI-generated invalid spam reports with them.
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...
1 reply →
> Many services, such as Google Docs, need to enable cross-origin framing for their functionality.
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?
> What specifically does Google Docs do that requires it?
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.
I tend to agree. See also: https://issues.chromium.org/issues/401081629
SVG and CSS filters can leak cross-origin data via iframes from March 6, 2025
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.