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)!
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?
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.
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.
You need to log in before you can comment on or make changes to this bug.