Trick users and bypass warnings – Modern SVG Clickjacking attacks
lyra.horse196 points by spartanatreyu 10 hours ago
196 points by spartanatreyu 10 hours ago
Reminds me of the flash player hack that would trick people into enabling system storage while hiding the menus. Vectors just can't help themselves
What a cool post! Really enjoyed reading it.
I already keep SVG disabled for security reasons, but it's increasingly looking like I'll have to find some way to disable CSS too. It's too bad people couldn't leave CSS alone as a nice simple (sort of) way to format text because turning it into another programing langue is begging for it to be abused by hackers and other malicious actors (like advertisers) just like JS
> It's too bad people couldn't leave CSS alone as a nice simple (sort of) way to format text
The base form of this attack goes back to the original CSS 1.
Honestly you are massively overreacting. This type of attack was much much easier to pull off in the late 2000s then it is now. Its basically impossible in practise now a days.
Maybe I’m a too much of a normie to understand, but surely keeping your secure data away from your browser must be better than securing the browser to the point that it stops working?
Any service that is exposed as a website that has data which you would like to keep secure = potentially hacked through attacks like these. It's usually not possible to choose to not have data available on internet connected services sadly.
Of course, by why not access those particular services in a more secure way? With other browser settings, another browser, or another machine altogether?
Turning off JS permanently is like keeping your wallet in a safe you carry around all the time because once in a while you need to visit the dangerous parts of the town.
What security reasons (other than that cited by this demo, which doesn't seem to work on most platforms)?
nah, that is overkill. the probability of falling for this is still tiny and it cannot break the sandbox, steal session cookies, or anything like that .
Sandbox escapes are discovered all the time (pretty sure I've read about a few just this past week) and there are a lot of other problems CSS can enable (ads, fingerprinting, etc)
why not disable javascript once and for all.
Most site shouldn't run any js after content is loaded.
I hope there's something like <body onload="js.disable()">
I can only do it manually in DevTool.
As a user: Browsers let you manually disable JS, but you can also use an extension such as NoScript (I do).
As a web developer: You can use Content Security Policy to limit or disable JS, as well as other resources such as CSS and images.
That's not relavent to the attack discussed in the article. These types of attacks do not involve javascript, nor could they due to the same origin policy.
Why on earth would you want to load JS before content is loaded but not after? If you are able to assemble the page based on data sources before loading the page, you can just server-render the damn thing and disable JS altogether?
JS is essential for polished UX when you have highly interactive components. Technically mapquest got server-rendered interactive maps working, but no one would choose that over the usability of Google Maps or OpenStreetMaps today
> Why on earth would you want to load JS before content is loaded but not after?
apparently, single-page-apps is an unstoppable trend. I tried to disable JS and 99% site won't work.
But for content sites, after the article is loaded, disabling JS provides a much better reading experience.
> but no one would choose that over the usability of Google Maps or OpenStreetMaps today
That's a valid use for JS. But if you think about it, can we make a js free map tool using technics from OP's article? https://codepen.io/rebane2001/details/OPVQXMv
I've got noscript which at least keeps JS off by default and allows me to selectively enable scripts by domain. Now I just a similar tool for CSS. Something that whitelists a sane set of features that can't be used (at least as easily) for interactivity, ads, fingerprinting, and other malicious activity while letting me explicitly blacklist annoyances (like scrollbar styles or sticky headers). The way things are going I'll probably need something similar for HTML too.
Does JS protect against this particular attack? It seems like it's mostly implemented in CSS and SVG.
The SVG adder is art. Love it.
I want my Flash back! :-(
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_...
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 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.
As someone who runs a site that uses inline SVG, this is unfortunate. Hopefully it won't be a problem for me.
Maybe I'm missing something, but it looks like it requires an iframe attack or an XSS to work correctly, both of which have page/server settings that can be used to avoid them.
It's easy to prevent clickjacking attacks by not allowing your website to be embedded in an iframe.
You can do that by either adding a header to your network requests, o̶r̶ ̶b̶y̶ ̶a̶d̶d̶i̶n̶g̶ ̶t̶h̶e̶ ̶f̶o̶l̶l̶o̶w̶i̶n̶g̶ ̶m̶e̶t̶a̶ ̶t̶a̶g̶ ̶t̶o̶ ̶y̶o̶u̶r̶ ̶p̶a̶g̶e̶:̶
̶<̶m̶e̶t̶a̶ ̶h̶t̶t̶p̶-̶e̶q̶u̶i̶v̶=̶"̶X̶-̶F̶r̶a̶m̶e̶-̶O̶p̶t̶i̶o̶n̶s̶"̶ ̶c̶o̶n̶t̶e̶n̶t̶=̶"̶D̶E̶N̶Y̶"̶>̶
EDIT:
According to MDN, it will only work by adding it to your headers. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
The modern way to do this is with the Content-Security-Policy: frame-ancestors directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
A long time ago there was a facebook clickjacking method that could make someone inadvertently share a link or like a page. The former required clicking a combination of colored buttons and was quite clever. This was in 2010. But it could not do more, like steal sessions.