Yes, you can have fun with downloads

It is an important and little-known property of web browsers that one document can always navigate other, non-same-origin windows to arbitrary URLs; in more limited circumstances, even individual frames can be targeted. I discuss the consequences of this behavior in The Tangled Web - and several months ago, I shared this amusing proof-of-concept illustrating the perils of this logic:

• http://lcamtuf.coredump.cx/switch/

Today, I wanted to showcase a more sneaky consequence of this design - and depending on who you ask, one that is possibly easier to prevent.

What's the issue, then? Well, it's pretty funny: predictably but not very intuitively, the attacker may initiate such cross-domain navigation not only to point the targeted window to a well-formed HTML document - but also to a resource served with the Content-Disposition: attachment header. In this scenario, the address bar of the targeted window will not be updated at all - but a rogue download prompt will appear on the screen, attached to the targeted document.

Here's an example of how this looks in Chrome; the fake flash11_updater.exe download supposedly served from adobe.com is, in reality, supplied by the attacker:

All the top three browsers are currently vulnerable to this attack; some provide weak cues about the origin of the download, but in all cases, the prompt is attached to the wrong window - and the indicators seem completely inadequate.

You can check out the demo here:

• http://lcamtuf.coredump.cx/fldl/

The problem also poses an interesting challenge to sites that frame gadgets, games, or advertisements from third-party sources; even HTML5 sandboxed frames permit the initiation of rogue downloads (oops!).

Vendor responses, for the sake of posterity:

• Chrome: reported March 30 (bug 121259). Fix planned, but no specific date set.

• Internet Explorer: reported April 1 (case 12372gd). The vendor will not address the issue with a security patch for any current version of MSIE.

• Firefox: reported March 30 (bug 741050). No commitment to fix at this point.

I think these responses are fine, given the sorry state of browser UI security in general; although in good conscience, I can't dismiss the problem as completely insignificant.