Updated Clickjacking Cheatsheet . Closes #1577

[caffeine-rohit]

Closes #1577 . I updated the Clickjacking cheat sheet by adding Double Clickjacking into it. I added all the necessary information about this issue and explained some good effective ways to prevent Double clickjacking .

[caffeine-rohit]

@jmanico @kwwall @szh @mackowski Please Review the PR . It closes #1577

[jmanico]

This is very new information to me, I will approve when @kwwall says go.

[mackowski]

@caffeine-rohit do you have PoC of this exploit somewhere? I am wondering if COOP https://web.dev/articles/security-headers#coop and CORP https://web.dev/articles/security-headers#corp can help to mitigate that.

[kwwall]

@mackowski wrote:

@caffeine-rohit do you have PoC of this exploit somewhere? I am wondering if COOP https://web.dev/articles/security-headers#coop and CORP https://web.dev/articles/security-headers#corp can help to mitigate that.

See Yibelo's Poc at https://www.paulosyibelo.com/2024/12/doubleclickjacking-what.html?m=1. Search for "Proof of Concept (PoC) Code" there.

I don't think that either COOP or CORP will be 100% effective as clickjacking attacks do not necessarily need to be "cross-site" even though they generally are. If one of those headers work, the more common SameSite: Lax/Strict cookies approach would probably suffice. Just my opinion. I'm waiting to hear from @jmanico on this.

[mackowski]

@jmanico can you also review this?

[jmanico]

@jmanico can you also review this?

I am not comfortable pushing this work live yet. It's very bleeding edge. I'd like more experts in this area to review this and chime in. @kwwall concerns are very valid.

[kwwall]

@jmanico can you also review this?

I am not comfortable pushing this work live yet. It's very bleeding edge. I'd like more experts in this area to review this and chime in. @kwwall concerns are very valid.

Jim, you need not "approve" this PR, but I was hoping that perhaps that you could at least provide some specific feedback, especially regarding to the JavaScript snippets. In the meantime, please ask any expert that you know to take a look at this.

I will also reach out to @jeremylong and see if he's willing to give this a look. If I could find any contact info for Paulos Yibelo, I'd reach out to him and invite his feedback. (Although I did find a promising lead, so will try it.)

[jmanico]

const observer = new IntersectionObserver(entries => {
    entries.forEach(entry => {
        if (!entry.isIntersecting) {
            alert("Warning: A hidden iframe may be attempting a Clickjacking attack!");
        }
    });
}, { threshold: 0.5 });
document.querySelectorAll("iframe").forEach(iframe => observer.observe(iframe));

This will likely cause a lot of false alarms. There are legit reasons for an iFrame to be off screen, like when a user scrolls away.

[kwwall]

const observer = new IntersectionObserver(entries => {
    entries.forEach(entry => {
        if (!entry.isIntersecting) {
            alert("Warning: A hidden iframe may be attempting a Clickjacking attack!");
        }
    });
}, { threshold: 0.5 });
document.querySelectorAll("iframe").forEach(iframe => observer.observe(iframe));

This will likely cause a lot of false alarms. There are legit reasons for an iFrame to be off screen, like when a user scrolls away.

@jmanico , is it possible to redeem this JS by enhancing it to check if the intersecting iframe is transparent (or almost transparent)? However, even that is possible, this seems like a relatively expensive check that could be abused as an intentional DoS attack, so maybe not. Like I said, I'm not a JS expert and neither did I stay at a Holiday Inn Express last night.

[caffeine-rohit]

@jmanico @kwwall Thanks for your input! The original approach was meant to detect hidden iframes but, as noted, it could indeed produce false positives.

A potential enhancement could be to check not only visibility but also opacity (getComputedStyle(iframe).opacity) and display properties to determine whether an iframe is intentionally hidden rather than just off-screen due to natural scrolling. However, adding transparency detection might introduce performance overhead, as mentioned.

Regarding DoS concerns, continuous checks on multiple iframes could be optimized with debouncing or rate limiting to prevent abuse. Do you have suggestions on how to improve efficiency while maintaining security?

[caffeine-rohit]

To refine this approach, we can:

1. Enhance detection by checking visibility, display, and opacity alongside isIntersecting to ensure the iframe is truly hidden.

2. Reduce false alerts by logging hidden iframes instead of triggering immediate alerts and verifying via user interaction.

3. Optimize performance with debouncing (e.g., 500ms) to prevent excessive checks and minimize DoS risks.

Would these refinements address the concerns?

[kwwall]

I managed to connect with Paulos Yibelo via LinkedIn and asked him if he could take a look at this PR and maybe comment on it. He said he is unable to respond at the moment, but will see if he can follow up in a few weeks. However, I did ask if I could pass along his comments and he agreed. Note that I have made some minimal edits to protect his privacy:

Hi Kevin, thanks for reaching out. ... I did peak at the link and see some references to iframes. DoubleClickjacking does not use iframes at all. It uses windows, hence why it can bypass mitigations that can only affect iframes. SameSite, CSO, XFO, coop, corp, etc can't defend against it for this reason. The first couple lines of my blog should highlight how it works plus with the reproduction steps. The PoC script needs to be hosted on an http/s page to work and won't work if u try it hosted on file:///

I thought these videos explained it pretty well:

https://youtu.be/pnQQ7NQ1ZPA?si=Ywu-fl2pR5QKvZBo and https://youtu.be/MpdTo2Csmi0?si=aeYtGt8Lqiai29A4

My mitigation works pretty well and is implemented by PayPal, GitHub, video, Stripe, Exodus, Dropbox ...

https://labs.sqrx.com/two-clicks-to-chaos-how-double-clickjacking-hands-over-control-of-apps-without-users-knowing-e921039816e9

All my code does is, if no gesture is detected, disables the button. From end-user experience there is zero disruption.

[mackowski]

@kwwall can you reach out to Paulos Yibelo to review this?

[mackowski]

@kwwall and @caffeine-rohit any updates on this?