full-disclosure - Re: silly PoCs continue: X-Frame-Options give you less than expected

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 11 Dec 2011 03:01:27 +0100
From: Christian Sciberras <uuf6429@...il.com>
To: Michal Zalewski <lcamtuf@...edump.cx>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>,
	bugtraq <bugtraq@...urityfocus.com>
Subject: Re: silly PoCs continue: X-Frame-Options give you
 less than expected

Michal,

Interesting stuff indeed. However, I don't see you talk about a solution.

Why is that?

It seems Mr 65 here knows something about it seeing that he's complaining
about Firefox not having taken any measures (as if anyone is taking them
seriously when it comes to security...).

Anyhow, correct me if I'm wrong, but this concept won't work when the
attacked
site requires multiple user interaction, right? As in, the user will notice
something
amiss the second time.
In terms of usefulness, I don't see it practical unless the target doesn't
really employ good security practices, in which case, it would probably
already be vulnerable to plain XSRF...

Cheers,
Chris.

On Sat, Dec 10, 2011 at 11:39 PM, Michal Zalewski <lcamtuf@...edump.cx>wrote:

> At the risk of annoying everyone...
>
> I think we greatly underappreciate the extent to which JavaScript
> allows you to exploit the limits of human perception. On modern
> high-performance systems, windows can be opened, positioned, and
> closed; and documents loaded and then navigated away from; so quickly
> that we can't even reliably notice that, let alone react consciously.
>
> The PoC I posted here earlier this week
> (http://lcamtuf.coredump.cx/switch/) demonstrates one example of page
> transitions occurring so fast that you don't register it; and some of
> my earlier posts outlined the exploitation of page switching to
> exploit browser UIs (e.g. http://lcamtuf.coredump.cx/ffgeo2/). Today,
> I wanted to share this brief demonstration of an attack that should
> hopefully illustrate why our current way of thinking about
> clickjacking (and the possible defenses, such as X-Frame-Options) is
> flawed:
>
> http://lcamtuf.coredump.cx/clickit/
>
> The basic idea here is that instead of placing the UI you want to
> tamper with in an invisible or only partly-visible <iframe>, you can
> achieve a similar effect simply by predicting the time of a
> premeditated click (which is fairly easy if you look at mouse velocity
> and distance to the expected destination), and then either destroying
> the current window, or navigating to a different document (in this
> case, a cheesy banking site).
>
> While everything about this exploit is extremely goofy, and I put no
> effort into making the transitions less obvious, it should still
> demonstrate the issue neatly.
>
> /mz
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/