1922452 - Google One Tap iframes can be clickjacked in Firefox, because they rely on IntersectionObserver v2 (which Firefox doesn't implement) to prevent clickjacking

Status: RESOLVED DUPLICATE of bug 1896900

(Core :: Layout, defect)

Description

[satrya wira yudha]

Attachment: bandicam 2024-10-03 13-41-11-235.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0

Steps to reproduce:

1. Create a clean firefox profile (no cache, default configs, etc.)
2. Sign in to your Google account
3. Go to https://pocs.lol/pocs/2024/google-one-tap-clickjacking/
4. if you log in with multiple email accounts. this attack is very easy for the attacker
5. Click on the "click me to see funny cats" button
6. Wait a few seconds
7. Your email should appear on the website
8. if the victim has clicked once. every time he visits the web the data will appear

Actual results:

details check my video

this is the same as the case on chrome that has been fixed https://issues.chromium.org/issues/333708039

Expected results:

this is the same as the case on chrome that has been fixed https://issues.chromium.org/issues/333708039

Comment 1

[Jan Jaeschke [:jjaschke]]

Attachment: Screenshot Nightly MacOS

Attached a screenshot of what I see when I open the page (the google account page is slightly visible). The blue box ("click me to see funny cats") is not clickable, the slightly visible blue box that says "Continue" is clickable. I'm on MacOS, current Nightly.

Comment 2

[Jan Jaeschke [:jjaschke]]

Therefore, I cannot repro. However, it's possible that it would repro if the blue box was moved so it is on top of the google box.

Emilio, can I put this on your radar?

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I mean, I'm a bit confused, is this really a bug in our IntersectionObserver implementation? Note we don't implement IntersectionObserver v2 which is what allows you to detect this kind of situation. So this is a nice PoC that we need to look at once we get to implementing bug 1896900...

Comment 4

[satrya wira yudha]

any update ?

Comment 5

[satrya wira yudha]

any update ?

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Not sure what update are you looking for other than comment 3. This depends on a feature we haven't implemented yet, so it's expected it doesn't work?

Comment 7

[satrya wira yudha]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

Not sure what update are you looking for other than comment 3. This depends on a feature we haven't implemented yet, so it's expected it doesn't work?

but now it's working. okay I'll wait

Comment 8

[Daniel Holbert [:dholbert]]

Clarifying things a bit here:

1. Google provides a "One-Tap SDK" that lets a web developer embed a google.com iframe that users can interact with, to sign in to the web developer's google-connected service. (If a user taps a particular button in this iframe, then that shares the user's email address with the developer as part of the sign-in.)
2. As part of that SDK, Google has a policy documented on https://developers.google.com/identity/gsi/web/guides/display-google-one-tap that web developers are not supposed to cover up this iframe. Violations "may result in project suspension or account suspension." In other words, they're acknowledging that this iframe can be clickjacked and they're asking folks to please not do that.
3. They have code running in the iframe to partially enforce this no-clickjacking policy; they do this using the IntersectionObserver v2 API (which lets an iframe determine whether it's fully-visible when events are received). This mitigation didn't initially work in Chrome, which is what the associated chromium bug is about.
4. Firefox doesn't implement IntersectionObserver v2 at all, so this mitigation trivially doesn't work in Firefox, which means the clickjacking attack does work, and this One-Tap SDK is reliant on its "please don't clickjack, violations may result in [...]" policy to protect itself.

Comment 9

[Daniel Holbert [:dholbert]]

This is arguably more of a hole in the Google One Tap SDK than a Firefox bug.

Typical clickjacking mitigations are documented at https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Clickjacking and
https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html
...and they're focused around ways that a page can either prevent itself from being served in an iframe at all, or be served in a not-logged-in-state.

In this Google One Tap SDK, Google seems to be opting out of those mitigations and explicitly giving web developers a way to embed a google-hosted frame on their site, with the users' login cookies intact in that iframe (so that users can just tap which account they want to use to sign in). And Google's relying on policy solutions like turning off developers' access to this API to mitigate abuse, combined with their IntersectionObserver v2-based as an additional mitigation for browsers that support that API (which is currently just Chromium-based browsers, per https://caniuse.com/intersectionobserver-v2 )

Comment 10

[satrya wira yudha]

(In reply to Daniel Holbert [:dholbert] from comment #9)

This is arguably more of a hole in the Google One Tap SDK than a Firefox bug.

Typical clickjacking mitigations are documented at https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Clickjacking and
https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html
...and they're focused around ways that a page can either prevent itself from being served in an iframe at all, or be served in a not-logged-in-state.

In this Google One Tap SDK, Google seems to be opting out of those mitigations and explicitly giving web developers a way to embed a google-hosted frame on their site, with the users' login cookies intact in that iframe (so that users can just tap which account they want to use to sign in). And Google's relying on policy solutions like turning off developers' access to this API to mitigate abuse, combined with their IntersectionObserver v2-based as an additional mitigation for browsers that support that API (which is currently just Chromium-based browsers, per https://caniuse.com/intersectionobserver-v2 )

Will you let this case remain?

Comment 11

[Daniel Holbert [:dholbert]]

For the time being, yeah, as discussed above. Once we ship IntersectionObserver v2, then Google's mitigation will become active in Firefox, but in the meantime they're explicitly opening themselves up to being clickjacked in browsers that lack support for IntersectionObserver v2 (which for now is all non-Chromium browsers), and there's not much we can do about that.

Comment 14

[Daniel Veditz [:dveditz]]

We don't need to keep this bug open as an example of how InsectionObserverV2 can help secure web sites.