[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Adam Barth]

Incidentally, these issues are why Collin's proposal at the start of
this thread was to list send the origin of all the ancestor frames:

On Thu, Sep 25, 2008 at 12:57 PM, Collin Jackson
<collin.jackson at gmail.com> wrote:
> make it an "X-Ancestor-Frame-Origin: http://www.evil.com" HTTP
> request header. This header could be a list of all the origins that
> are ancestors of the frame that triggered the request. If the site
> decides it does not like the ancestor frame origin it could reject the
> request. This could be added as a property of MessageEvent as well to
> detect client-side UI redress attacks.

This proposal blocks the attack after the user clicks the bad button
(instead of when the bad site tries to load the good site in a frame).
 The proposal works in the cases below because the attacker's frame is
one of the ancestor frames when the "clickjack" click occurs.  (The
proposal is the visual analog of "stack inspection" in other systems.)

Adam


On Mon, Sep 29, 2008 at 1:52 PM, Adam Barth <whatwg at adambarth.com> wrote:
> On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren <annevk at opera.com> wrote:
>> Hmm, we went through this before I believe.
>
> Yeah, we talked about this in the context of CSRF.
>
>> I thought the issue with Referer
>> was that it exposed path information, but I guess the problem with Origin is
>> that it reveals the intranet server name?
>
> The query string and the path are probably the most privacy-sensitive.
>  Yes, the concern is revealing the name of an intranet server.  Most
> names are probably innocuous (like www, hr, or wiki), but there are
> others that might be an issue (like secretproject).  It's hard for me
> to evaluate how concerning this privacy leak is.
>
>> On the other hand, for the
>> not-link following case how common is it for intranet applications to load
>> images and resources cross-site?
>
> I don't have numbers to back this up, but my guess is that hyperlinks
> are far-and-away the most predominant.
>
> For CSRF, it doesn't make sense to send the Origin header for some
> kind of GET requests but not for others (the attacker will just use
> the method that doesn't send the header).  For UI redress /
> clickjacking, the attacker can make the request using hyperlinks also.
>  For example:
>
> 1) http://attacker.com/ embeds a frame to http://attacker.com/ready
> 2) http://attacker.com/ready has a hyperlink to http://victim.com/
> that gets clicked by JavaScript (say via the click() method).
>
> Keep in mind, that the attacker can often launder the IFRAME request
> through a respected third-party.  For example, the image search
> features offered by Live.com, Google, and Yahoo all happily create
> IFRAMES to a URL of the attacker's choice.
>
> Adam
>