[whatwg] Fixing two security vulnerabilities in registerProtocolHandler
ian at hixie.ch
Fri Apr 6 15:36:40 PDT 2012
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
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg