[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Ian Hickson]

On Fri, 6 Apr 2012, Tyler Close wrote:
> >
> > Well if it's an iframe, the parent can't be anything but the original 
> > origin, as far as I can tell.
> 
> What happens if the handler sends the postMessage to "*", then the 
> parent is navigated? Will the postMessage be delivered or not?

A task queued on a Document is associated with that Document and can only 
be processed when that document is active.


> > But in general, there's not expected to be any talking back. If you 
> > want something where the handler talks back to the page that provided 
> > the data, then you should use Web Intents. registerProtocolHandler() 
> > and registerContentHandler() are intended for things like mail clients 
> > (mailto:) or PDF viewers, which do not talk back. Indeed in the common 
> > use case, you just click the link and the entire browsing context gets 
> > replaced, so there's nothing to talk back _to_.
> 
> I was prompted to write the original email by a Mozilla blog post that 
> suggested talking back.
> 
> It also seems bad for web APIs to break under simple composition like 
> this; especially when there's an easy fix available.

I think it's unsurprising that a feature would not be suitable for a task 
for which it was not designed. Turns out <canvas> is really bad at cross- 
document communication too. ;-)

In the case of <iframe>, there's no problem since you can't post anything 
to a parent that isn't the parent that spawned you.

In the case of window.open, it's true that the opener could have navigated 
by the time you try to communicate back. That's a general problem with 
window.open(), though; it's not specific to register*Handler(). The 
solution is to not use window.open(), which is in any case bad UI.


> > For such an example, you can just use a fallback section in the 
> > appcache manifest. (Or a fragment identifier, indeed.)
> 
> Right, the obvious thing to do is use the fragment identifier, but 
> that's got some security problems. With a small tweak we can make this 
> safe and easy.

I don't understand the security problem. Could you give a concrete example 
of an attack scenario?


> > Why would a mail client talk back to its opener?
> 
> It might not, but some RPH handlers will.

Why? What's the use case?


> > I don't understand the attack scenario. Sure, a Web page can open 
> > another Web page with arbitrary arguments. Why does it matter here?
> 
> Two reasons:
> 1. An RPH dispatch is different from a direct load because it 
> communicates a user choice to the RPH handler. I explained above how a 
> handler might use this information.

I don't see how this difference affects the security here.


> 2. An RPH dispatch comes from the browser, so URL parameters can be 
> trusted; whereas they cannot be trusted in a load from another web page.

I don't see how they can be viewed as "trusted".


> With a small change, we can prevent a client page from faking an RPH 
> dispatch to a handler page.

It's just a page load, not a "fake RPH dispatch". I don't understand the 
problem here.

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