> Exploiting Clickjacking on Google YOLO allows visitors' name, profile picture and email address to be leaked. That's right, I can even know your email address. :). Click here if you want to see behind the sense (make sure you have logged in Google with a modern browser, PC preferably).
Google's reply to a VRP submission:
> Thanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug.
> The login widget has to be frameable for it to work. I'm not sure how we could fix this to prevent this problem, but thanks for the report!
Yeah, I read through the post and (assuming I'm parsing it right) can't figure out why this hasn't caused a massive shitstorm already. Are they actually arguing that it's not a security bug because it's necessary for them to implement a 'one click sign in through Google' feature?
Likejacking Facebook likes has been around for 8+ years, leaks a similar amount of information, and there’s no big shitstorm. Not sure what the big difference between YOLO and FB’s like button are?
I was wondering whether this is actually the same as like jacking. Is the ‘leak’ in that case the ability for the Facebook page/post owner to be able to then look you up in the list of ‘likes’? If so, I think Facebook privacy settings may allow users to not leak their emails or pictures in this case.
Also, I think it’s more widespread given that ‘Google identity’ covers a large number of Google products, and signing into one signs into all. With Facebook any time I log in nowadays I open incognito, check messages, log out, whereas with Google I generally stay logged in, mostly because I want gmail and my cross device browsing history to work.
Exactly. If it was about "just whitelisted partners" he discovered it was actually "everybody." It's not different than discovering that instead of the password just an empty string is enough.
Project PR exercise? doubt it, they only seem to pick holes in other companies software, if they ever took a long hard look at Android for instance then I imagine they could find a ton of problems, which is probably why they haven't, at least to the best of my knowledge.
Indeed. A Google engineer stated on Twitter [0] that the shutdown of the service happened because apparently YOLO is only supposed to be accessible to whitelisted partners.
They also state in the same Twitter thread that they were aware of the issue before the blog post was written. IANAL but even if the shutdown was intentional (as opposed to being the example of terrible damage control it looks like), willfully leaving a bug in production that allows a set of whitelisted partners to deanonymize their visitors without their consent seems like something that shouldn't fly in countries with data protection laws?
I just received a message back on Twitter saying that the whitelist wasn't the fix and they are still making more changes.
This is seriously denting my continued belief in Google's security chops. I know they have some of the finest security researchers on the planet but this was handled in a ham-fisted and ineffective way so far.
And best of all: without 'partner' status you won't be able to check if has been fixed.
>This is seriously denting my continued belief in Google's security chops. I know they have some of the finest security researchers on the planet but this was handled in a ham-fisted and ineffective way so far.
This is a great demonstration how a company can have all of the right talent but still manage to become incompetent through poor organizational policies.
It would be fine if they only gave whitelist access to people who could already simply access your data by request. But GDPR would only require that they know who could access, and that the access list be less than "the entire world".
They're burning developers and potential employees trust in the first place. This "we don't know how to fix it ==> not a bug" attitude is what's staggering.
This keeps happening over and over again. I remarked the other day that the most feared words when reporting a serious bug are 'won't fix'. It is super annoying. If the feature can't be made to work safely then drop the feature.
To fix this, there could be a new `X-Frame-Options`: `compose-over`. The browser rendering context will compose the frame separately, and always place it on the top of the rendering context, above every other element; regardless of the host page element's z-index, opacity, whatever.
It's kind of like how an app cannot draw over system UI; like the permissions dialog.
I'm surprised this is not how X-Frame-Options worked in the first place.
Or maybe logging in ought to be handled directly by the browser in a way that couldn't be highjacked or phished easily. Do we really need a million different implementations of a login form?
I recall a video talking explicitly about this problem - it was something about using the browser paint API in conjunction with iframes for security? The gist was a browser should be able to tell in real time if an iframe is visible and should be able to block user input depending on whether or not the site was hiding the iframe, putting something on top of it, pushing it off screen, moving it around, etc...
But I can't remember the source. If I can find it, I'll add it in an edit. And of course if anyone else knows the talk I'm thinking of, please link.
It certainly makes me glad I did _this_ on my FB account:
>>
You previously turned off platform apps, websites and plug-ins. To use this feature, you need to turn them back on, which also resets your Apps others use settings to their default settings.
<<
.. but further to that, I should take my FB login and stick it in a Firefox container where it belongs.
NoScript includes protection against this! He calls it ClearClick:
" whenever you click or otherwise interact, through your mouse or your keyboard, with an embedded element which is partially obstructed, transparent or otherwise disguised, NoScript prevents the interaction from completing and reveals you the real thing in "clear". At that point you can evaluate if the click target was actually the intended one, and decide if keeping it locked or unlock it for free interaction."
I don't think so. Chrome's site isolation just isolates different origins in different browser processes, whereas Firefox's first party isolation is intended to isolate _cookies_.
> Shortly after thie article was published, Google silently prevented my domain from using the API:
> The client origin is not permitted to use this API.
> Welp.
So some buttons stoped working, and now you have to believe that everything was as the blog said. Well, it was.
And a "mitigation" from google being just avoiding the access to the API just makes things more interesting.
A lot of Google employees are reading HN and actively posting so no surprise. Did they at least contacted you to properly open a ticket now that they implicitely recognized the vulnerability? Otherwise very very dickish move as it solve nothing and you basically worked for free...
And now if anybody from HN team is listnening. Can you explain why this thread is fastly slipping from the front page?
Currently it’s being devanced by articles that are olders, with less upvote and fewer comments. Can you guarantee that nobody is able manipulate ranking? It’s only a hunch, but it’s not the first time that I notice that google related "bad buzz" move away from main page slightly faster than other...
PS: I’ll gladly accept downvotes. But answers on why I’m wrong or paranoid would have been better
There appear to be quite a few flags on the article pushing it down. The ratio of upvotes to age compared to the rest of the front page is a strong indicator of this.
Also: lots of HN'ers work at google. It would be a nice rule if people were told to abstain from using their flagging privileges when the company they work at is the subject of a thread.
It's probably because a lot of Google folks are on here - protecting their brand. Unfortunately that part isn't transparent, but its hopefully a minor issue.
You may be protected from the specific examples provided in the blog post, but, on the whole, you will not be protected. Most of the underlying vulnerabilities here can be exploited with simple HTML and CSS.
Content blockers can also prevent embedded iframes from loading. The article looks like this for me using uMatrix in Firefox: https://i.imgur.com/pYFXRR3.png
Clicking the link opens the iframe in a new tab, so it's hard to click it again without noticing what's going on.
You can make it a bit more visible if you use the Stylus extension.
Unfortunately Chrome (and probably Firefox quantum) doesn't let you apply css agent_sheets (only user/author), so that style="display:none!important" on the iframes can't be overridden.
If you use older Firefox or Palemoon then you can use Stylish v2.0.7 and override it.
I saw it, immediately thought "this is clearly part of the demo", and clicked it, because I was certain it was going to be fun. Woe betide me and my poor risk valuation skills - but not today.
I'm looking forward to Google giving out a $100 reward or even nothing to the researcher.
Like they did to the guy who found the sitemap ranking bug in Google Search where he was able to let others pay for a first page ranking. He only got $1,337 and it took Google 6 months to fix it.
Unfortunately that is true, and it's really bad for accessibility too (using links as buttons, but not coding the keyboard events that are used on buttons, for example.
Well, yes; you double-click the play button to play the video/iframe. I'd be more worried about "Oh, the button did nothing, I should try again.". The real fix is to not allow transparency/compositing.
Yes, if you aren't signed in to other accounts most of these click jacking scenarios would need to convince you to sign in which would be pretty obvious.
Well, elinks is a cul-de-sac, and AFL would probably obliterate it, so elinks users are most probably putting themselves in more danger than they avoiding.
I won't vote either way, but I will say that regardless of what GDPR may mean, "you need a cookie warning" will be accepted web dev mantra for years, and the things they build in that time will be around longer still.
It's impossible to run a website that does anything significant (such as show ads, use UX to convert visitors, or even log in) without cookies.
The regulators don't even understand this, and nowhere has anyone gone on record saying this ignorant and misguided law was secretly intended to push an industry to "self-regulate" (regulate what, one wonders?)
GDPR being a response to anything having to do with cookies is only your interpretation, and a fairly absurd one at that.
Lastly, no one said you have to like web devs, but HN requires you to be civil, so I suggest you save the hatorade for Reddit.
You mentioning "log in" in this context makes it pretty clear you're also fairly ignorant about the specific topic. Log ins, shopping baskets, ... do not require a cookie notice.
Not only is what you're saying irrelevant to my point, you're wrong. "Log ins, shopping baskets" do require a notice if they are persistent, which almost all of them are. Looks like you're the ignorant one here.
> This report will unfortunately not be accepted for our VRP. Only first reports of technical security vulnerabilities that substantially affect the confidentiality or integrity of our users' data are in scope, and we feel the issue you mentioned does not meet that bar :(
Or maybe that simply mean this is not the FIRST REPORT of that technical security vulnerability that substantially affect the confidentiality or theirs user’s data.
Interesting discovery: The facebook-like clickjacking doesn't work on Firefox when I have Facebook in its own tab-container (even though I'm logged in, just in that container, not the one I clicked on).
I'm not sure what the minimal repro is here, but if it's the containerization working as intended, that'd be awesome.
This is the intended effect! And if you use the dedicated Facebook Container it's even stronger. The Like button will be blocked entirely, so even Facebook won't receive the "Like" action. https://addons.mozilla.org/en-US/firefox/addon/facebook-cont...
According to an update on the OP post Google apparently now silently blocked the OP webpage, so the exploit doesn't work in this case - but will still work for any other malicious page. Not cool Google.
241 comments
[ 0.19 ms ] story [ 937 ms ] thread> Exploiting Clickjacking on Google YOLO allows visitors' name, profile picture and email address to be leaked. That's right, I can even know your email address. :). Click here if you want to see behind the sense (make sure you have logged in Google with a modern browser, PC preferably).
Google's reply to a VRP submission:
> Thanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug.
> The login widget has to be frameable for it to work. I'm not sure how we could fix this to prevent this problem, but thanks for the report!
That's why we don't trust login widgets, right?
Also, I think it’s more widespread given that ‘Google identity’ covers a large number of Google products, and signing into one signs into all. With Facebook any time I log in nowadays I open incognito, check messages, log out, whereas with Google I generally stay logged in, mostly because I want gmail and my cross device browsing history to work.
By the terms of the VRP it sounds like the reporter is owed a payout.
Maybe someone should tip off Google project Zero about this? Let's see if they mean it that they will hold themselves to the same standard.
[0]: https://stackoverflow.com/questions/50289065/google-yolo-sto...
[0]: https://twitter.com/sirdarckcat/status/994867632355577862
I'm sure that will go down just fine. FB just got into a lot of trouble over something like that (arguably a lot more serious, but still).
This is seriously denting my continued belief in Google's security chops. I know they have some of the finest security researchers on the planet but this was handled in a ham-fisted and ineffective way so far.
And best of all: without 'partner' status you won't be able to check if has been fixed.
This is a great demonstration how a company can have all of the right talent but still manage to become incompetent through poor organizational policies.
I want to say that I hope this is isolated and not a systemic part of their company culture but at this point I can't help but be cynical after this.
It's kind of like how an app cannot draw over system UI; like the permissions dialog.
I'm surprised this is not how X-Frame-Options worked in the first place.
I recall a video talking explicitly about this problem - it was something about using the browser paint API in conjunction with iframes for security? The gist was a browser should be able to tell in real time if an iframe is visible and should be able to block user input depending on whether or not the site was hiding the iframe, putting something on top of it, pushing it off screen, moving it around, etc...
But I can't remember the source. If I can find it, I'll add it in an edit. And of course if anyone else knows the talk I'm thinking of, please link.
https://m.youtube.com/watch?v=9wx2TnaRSGs
https://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickj...
It certainly makes me glad I did _this_ on my FB account:
>> You previously turned off platform apps, websites and plug-ins. To use this feature, you need to turn them back on, which also resets your Apps others use settings to their default settings. <<
.. but further to that, I should take my FB login and stick it in a Firefox container where it belongs.
" whenever you click or otherwise interact, through your mouse or your keyboard, with an embedded element which is partially obstructed, transparent or otherwise disguised, NoScript prevents the interaction from completing and reveals you the real thing in "clear". At that point you can evaluate if the click target was actually the intended one, and decide if keeping it locked or unlock it for free interaction."
https://hackademix.net/2008/10/08/hello-clearclick-goodbye-c...
https://www.chromium.org/Home/chromium-security/site-isolati...
So some buttons stoped working, and now you have to believe that everything was as the blog said. Well, it was.
And a "mitigation" from google being just avoiding the access to the API just makes things more interesting.
https://twitter.com/LiveOverflow/status/994560352149999616
Currently it’s being devanced by articles that are olders, with less upvote and fewer comments. Can you guarantee that nobody is able manipulate ranking? It’s only a hunch, but it’s not the first time that I notice that google related "bad buzz" move away from main page slightly faster than other...
PS: I’ll gladly accept downvotes. But answers on why I’m wrong or paranoid would have been better
Also: lots of HN'ers work at google. It would be a nice rule if people were told to abstain from using their flagging privileges when the company they work at is the subject of a thread.
Big companies trying to strangle hold the small ones -- nothing new, time to move on. Its pathetic.
In an article like this I can't help but think that the "[ ] Behind the scene" button is the real bait.
Clicking the link opens the iframe in a new tab, so it's hard to click it again without noticing what's going on.
Unfortunately Chrome (and probably Firefox quantum) doesn't let you apply css agent_sheets (only user/author), so that style="display:none!important" on the iframes can't be overridden.
If you use older Firefox or Palemoon then you can use Stylish v2.0.7 and override it.
Like they did to the guy who found the sitemap ranking bug in Google Search where he was able to let others pay for a first page ranking. He only got $1,337 and it took Google 6 months to fix it.
Article for those interested: http://www.tomanthony.co.uk/blog/google-xml-sitemap-auth-byp...
A large chunk of the user base doesn't know the functional difference between icons, hyperlinks and buttons.
What do you mean by being "safe from AFL"?
A failure to verify SSL certificates has plagued elinks since 2012 [0]. Some versions protect, but the bug returns.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694658
In future I will dismiss cookie consent buttons by deleting it's DOM node from the inspector.
EDIT: Please research the GDPR and new ePrivacy regulation before you vote.
The goal was to let users opt out of tracking in the hope that the industry would self-regulate.
Now that it hasn't, GDPR is coming down hard.
Web devs really manage to fuck everything up.
It's impossible to run a website that does anything significant (such as show ads, use UX to convert visitors, or even log in) without cookies.
The regulators don't even understand this, and nowhere has anyone gone on record saying this ignorant and misguided law was secretly intended to push an industry to "self-regulate" (regulate what, one wonders?)
GDPR being a response to anything having to do with cookies is only your interpretation, and a fairly absurd one at that.
Lastly, no one said you have to like web devs, but HN requires you to be civil, so I suggest you save the hatorade for Reddit.
https://news.ycombinator.com/item?id=16575304
Do the right thing Google.
Which is in a way even worse :(
"If you think we've misunderstood or can provide a convincing attack vector, please do let us know!"
I think OP did not post this line in the blog; which makes Google look like they don't at all care.
I use this to close them; https://news.ycombinator.com/item?id=16575304
I'm not sure what the minimal repro is here, but if it's the containerization working as intended, that'd be awesome.