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

[Adam Barth]

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