[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Ian Hickson]

On Mon, 9 Apr 2012, Tyler Close wrote:
> On Mon, Apr 9, 2012 at 4:48 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 9 Apr 2012, Tyler Close wrote:
> >>
> >> The RPH handler doesn't need to know which is the legit site. The RPH 
> >> handler just needs to know that it's getting the RPH data from the 
> >> site that the user was interacting with, not some other unseen site 
> >> running in the browser.
> >
> > Nothing we have discussed so far would provide such a guarantee.
> 
> Yes, what I am proposing provides that guarantee. When an iframe is 
> initially navigated to a mailto URL, the browser starts its RPH dispatch 
> logic. In Firefox, this means a Picker dialog is shown and the user 
> selects an RPH handler. The browser then navigates the iframe to the RPH 
> handler URL and, under my proposal, would populate a DOM field 
> containing the mailto URL.

Nothing in the spec guarantees that a picker dialog is shown. Indeed, the 
specification is specifically designed to allow sites to be marked as 
default handlers, and in typical operation that would likely be the 
preferred behaviour for users. (Users don't typically want to pick a new 
PDF viewer or e-mail client every time they click on a PDF or mailto: link.)


> Alternatively, the browser could refuse to do repeated RPH navigation of 
> the same iframe.

That would break a use case such as a site with an index of PDFs opening 
in an irame, if the PDF viewer was a handler rather than a plugin.


> >> The vulnerability is that window.location can be overwritten by other 
> >> code running in the browser.
> >
> > Then we should fix _that_.
> 
> I was under the impression that the descendant policy on frame 
> navigation was baked into the Web at this point and could not be 
> changed.

As far as I can tell, at least some browsers prevent anything but the 
fragment identifier being changed in certain cross-origin cases. I haven't 
studied this in depth recently, but I strongly suspect that the rules 
currently in the spec regarding access to Location object members (which 
block the access you are describing for scripted navigations as well as 
window.open() and target="" navigations) do not need to be relaxed beyond 
merely allowing changes to fragment identifiers. As I mentioned, the 
implications if we do not limit them beyond this are far more dramatic 
than a site making a handler use a different URL.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'