Bug 457011 (clickjacking)

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

NEW
Unassigned

Status

()

defect
--
major
11 years ago
5 months ago

People

(Reporter: ladamski, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug, {meta, sec-want})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want], URL)

(Reporter)

Description

11 years ago
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)!
Whiteboard: [sg:investigate]
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?
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?
Whiteboard: [sg:investigate] → [sg:moderate]

Updated

10 years ago
Group: core-security
Depends on: 475530
(Reporter)

Comment 4

10 years ago
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
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.
Duplicate of this bug: 490590

Updated

9 years ago
Alias: clickjacking
Depends on: 519928
Keywords: meta
Summary: Clickjacking bug aka forced navigation → [meta] Ideas for preventing clickjacking (aka forced navigation, UI redressing)
Whiteboard: [sg:moderate] → [sg:nse meta]

Updated

9 years ago
Depends on: CSP

Updated

9 years ago
Depends on: CVE-2010-1125

Updated

9 years ago
Blocks: csrf

Comment 7

9 years ago
(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

9 years ago
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.
Blocks: 624883
Whiteboard: [sg:nse meta] → [sg:want]

Updated

8 years ago
Depends on: CVE-2012-1964
You need to log in before you can comment on or make changes to this bug.