[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Tyler Close]

On Fri, Apr 6, 2012 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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.

I'll assume that means it's not delivered, even though postMessage is
a method on a Window, not a Document.

> 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.

A top-level window is the only context in which you can ask the user
to engage in security-sensitive interaction, like entering a password,
or making a selection that must not be vulnerable to clickjacking.

>> > 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?

It is well-understood that URL fragment messaging is vulnerable to
tampering between windows or frames in the browser. Boris already
posted further clarifying this point and you seemed to understand. I
don't know what you're confused about.

>> > Why would a mail client talk back to its opener?
>>
>> It might not, but some RPH handlers will.
>
> Why? What's the use case?

So, it seems you're arguing that the Mozilla blog post was silly and
developers won't try to solve problems that way. Is that so?

>> > 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.

Well, perhaps it's not strictly necessary for you to understand it.
It's sufficient to understand that we want to enable offline RPH
handlers, without using a known bad technique like URL fragment
messaging.

--Tyler