[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Ian Hickson]

On Mon, 26 Sep 2011, Tyler Close wrote:
>
> I was recently experimenting with the registerProtocolHandler (RPH) API 
> and came across a couple of security gotchas that make it hard to safely 
> use the API. One of these is already known, but AFAICT, hasn't been 
> fixed yet. I haven't seen the other discussed yet.
> 
> The Mozilla blog post that introduces the registerProtocolHandler API 
> makes use of window.parent.postMessage to send a response from the RPH 
> handler back to the client page.

I presume it uses this in conjunction with an <a href=""> link with a 
target="" attribute to load the handler in an iframe.


> In the example code, the targetOrigin for this postMessage invocation is 
> '*', while also noting that this is not secure. AFAICT, there is no API 
> that the intent handler can reliably use to determine the correct 
> targetOrigin for this postMessage invocation.

How can the origin be anything other than the origin of the page that 
triggered the link?


> I suggest fixing this problem by adding a new readonly DOMString that 
> contains the correct origin for the postMessage invocation; perhaps 
> document.origin. So the response invocation would then be coded as:
> 
>   window.parent.postMessage('my response data', document.origin);
> 
> Perhaps a different name or location is better for this field, so I'll 
> defer to the editor's judgment.

You can work out your own origin from window.location's members, but I 
don't see how this helps you determine the origin of your parent. There's 
a separate thread about adding a way to obtain your parent's origin, but 
again, I don't see why you would need it in this case. Can you elaborate 
on what the attack scenario you are envisaging is?


> The second problem with RPH is that the handler page doesn't have a
> way of reliably getting the URL of the content to be handled from the
> browser. In order to work in offline scenarios, the RPH handler must
> put the %s placeholder in the fragment of its handler's URL.

It's not clear to me that it makes sense to have an offline protocol 
handler. What kind of protocol do you have in mind?


> Unfortunately, this means that other content in the browser could
> modify the content URL before the handler reads it.

Well, any content can load any URL, so it doesn't matter whether the URL 
is in the fragment identifier or the path or anything else, surely.


> For example, an attacker could open a window on a victim web page. The 
> victim web page then opens an <iframe> on a content URL that triggers 
> RPH. The attacker then navigates the <iframe> so that its 
> window.location contains a different content URL.

How can the attacker navigate that iframe? Surely it would not be allowed 
to navigate it, per the "allowed to navigate" definition in HTML.


> The intent handler sees a request coming from the victim page, but with 
> a content URL specified by the attacker. A related problem is that the 
> intent handler has no way to distinguish whether its URL was loaded via 
> the browser's RPH handling, or whether the client page directly 
> navigated to the intent handler's URL. Both of these problems could be 
> fixed by adding another readonly DOMString to the API that contains the 
> %s data for the RPH invocation.

I don't understand why it matters how the URL was invoked.

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