[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Tyler Close]

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. If at any point in this sequence an
attacker navigates the iframe to a different, non-RPH URL, that page
loads and the browser does not populate the RPH DOM field (since it's
not an RPH navigation). If the attacker navigates the iframe to
another RPH URL, then Firefox will show another Picker dialog, making
the attack visible. Alternatively, the browser could refuse to do
repeated RPH navigation of the same iframe.

>> 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. We also want RPH dispatch to be secure in cases where the
client is an iframe, not a top level page. For example, a widget
running on a social networking page should be able to securely send
data to a user selected RPH handler.

--Tyler