457011 - (clickjacking) [meta] Ideas for preventing clickjacking (aka forced navigation, UI redressing)

Status: RESOLVED WORKSFORME

(Firefox :: Security, defect)

Description

[Lucas Adamski [:ladamski]]

Using multiple iframes and onblur event handlers an attacker can trick the user into clicking on links by continually positioning the link the attacker wants the user to click on underneath the mouse cursor.  

Since the link itself is masked into a tiny/opaque iframe the uesr has no clue what they are actually clicking on, and since the link follows the cursor around delays on dialog buttons are not an effective mitigation.

See link for full write-up (not public)!

Comment 1

[Jesse Ruderman]

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html is public.

Comment 2

[Johnathan Nightingale [:johnath]]

http://www.milw0rm.com/exploits/7842

Variation on the same clickjacking theme, the PoC gets you to click on a legitimate link to google.com (which the status bar faithfully represents as google) but onclick, it moves a div containing a hostile link to be under the mouse, and hence becomes the click target.

Verified on 3.1, I suspect trunk too.  Does this new attack need a different bug?

Comment 3

[Giorgio Maone [:ma1]]

Looks like a pointless PoC to me, and not even "Clickjacking" as we currently define it. 
It requires JavaScript to be allowed on the page, therefore why should I go through all that link scrambling pain when I could just use
<a href="http://www.google.com" onclick="location.href='http://evil.com'; return false">http://www.google.com</a>
anyway?

Comment 4

[Lucas Adamski [:ladamski]]

IE is planning a declarative framing break-out HTTP header: http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx

Comment 5

[Giorgio Maone [:ma1]]

Lucas, it's not just planned, it's been shipped on Monday and I filed bug 475530 (which this bug already depends on) for parity yesterday.

See http://hackademix.net/2009/01/28/ie8s-clickjacking-protection-exposed/ for more discussion.

Comment 7

[Black_Ps`]

(In reply to comment #3)
> Looks like a pointless PoC to me, and not even "Clickjacking" as we currently
> define it. 
> It requires JavaScript to be allowed on the page, therefore why should I go
> through all that link scrambling pain when I could just use
> <a href="http://www.google.com" onclick="location.href='http://evil.com';
> return false">http://www.google.com</a>
> anyway?

This script can't be send on e-mail ,if you send it on yahoo,gmail or any other e-mail and click http://www.google.com it will load http://www.google.com and not evil.com onclick is not working on e-mails

Comment 8

[lists.bugzilla]

Does anybody know of actual sites that would break if browser-based storage items (cookies, etc.) were separated by the origin of the top-level window? While that would still allow malicious sites to insert iframes to other sites, the user wouldn't be logged in to those other sites (because they belong to a separate origin), and so any jacked clicks would have significantly less harmful effects. This is similar to Collin's suggestion #6 at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016286.html but can be implemented entirely on the browser side.

This separation would have an additional advantage/disadvantage that websites will have one less vector to track users across the web (i.e. the embedded Facebook 'like' button and Google analytics scripts will no longer receive user identification cookies even if the user is logged in to those sites). I think this is a win for the average user, although obviously opinions on this will depend on which side of the fence you sit.

Comment 9

[Negritas Sergiu, Desktop QA]

Hello!
I have tried to reproduce the issue with the links provided from the comments but some of them aren't working anymore.
As no activity has been done in the past 10 years I will mark this issue as RESOLVED-WORKSFORME if the issue is still valid please feel free to reopen this issue.

Thank you