[whatwg] Fixing two security vulnerabilities in registerProtocolHandler
ian at hixie.ch
Mon Apr 9 17:24:52 PDT 2012
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg