[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Jonas Sicking]

Why is this so complicated?

It seems clear to me that there is a use-case for sending a message to
your parent frame, but only wanting to do so when your parent frame is
from the same origin as you.

There appears to be to ways of doing so right now:

1. Hardcoding the origin as a literal
2. Assembing your origin together using the various properties on
window.location

1 is a bad solution for libraries or for when your application can run
on multiple domains. For example if you have separate staging domains,
if your site runs both on http and https, or if it runs on both
www.x.com and x.com.

2 is always a bad idea since people are sure to do this wrong. When it
comes to security we don't want people parsing or assembing strings in
order to figure out security contexts. Security contexts should be
made available directly so that people don't shoot themselves in the
foot.

There's currently way too few places in the platforms where we expose
origins, and too many where we expose domains.

/ Jonas

On Mon, Apr 9, 2012 at 3:12 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 9 Apr 2012, Tyler Close wrote:
>>
>> The browser's popup blocker would block that interaction, unless you
>> require an additional click inside the iframe. UX people are generally
>> fanatical about eliminating extra user clicks.
>
> I'm suggesting sending the information at the same time as you currently
> open the window.
>
>
>> For RPH to be used in an offline scenario, the %s argument is put in the
>> URL fragment component of the RPH handler's URL.
>
> It can also be put in the query or path component, if the relevant path is
> marked as being a FALLBACK namespace.
>
>
>> Here's another concrete attack scenario showing how this vulnerability
>> could be exploited in a mailto RPH handler. Consider a site that
>> requires a user to confirm a security sensitive operation by sending an
>> email with a confirmation number in the Subject field. The site expects
>> this email to be signed by the user's mail software. The web page that
>> sets up this user interaction includes a mailto link to open a
>> pre-populated email editor. This mailto: link includes a subject
>> parameter that contains the confirmation number. The attacker has
>> previously setup an operation that is waiting on such an email
>> confirmation from the victim user. The attacker has additionally lured
>> the user into browsing the legitimate site in a window that the attacker
>> has a reference to. The attack page waits for an iframe to show up in
>> the legitimate site's frame hierarchy at the place where a mailto RPH
>> confirmation action is being done.
>
> It seems highly weird to me that anyone would use a mailto: link with a
> target="" attribute, but ok.
>
>
>> The attack page overwrites the iframe's URL fragment with a mailto URL
>> that contains a subject parameter specifying the confirmation number for
>> the operation setup by the attacker, instead of the one that the victim
>> user was setting up.
>>
>> The user sends the email, confirming the attacker's operation, instead
>> of their own. From the user's perspective, they see that they are at the
>> legitimate web site and they setup an operation in the normal way which,
>> as expected, opens an email editor with a confirmation number. The user
>> typically never looks closely at the confirmation number, it's just some
>> number chosen by the legitimate web site. So, everything looks normal to
>> the user. From the perspective of the RPH handler page, everything also
>> looks normal. It opens and finds a mailto URL in the %s position in it's
>> URL fragment. It has no idea that the URL fragment has changed since the
>> legitimate site first specified it.
>
> It doesn't even have any idea that there is a legit site.
>
>
>> We can fix this by putting the %s data in a DOM field that cannot be
>> overwritten by an attacker in this way.
>
> That's what Web Intents does, but it doesn't really help with the
> server-side implementations of handlers, which are the expected common
> case here, and it doesn't even really help with the client-side
> implementations of handlers, who have no way to know who is "legit".
>
>
>> Consequently, the legitimate site can securely pass a confirmation
>> number to the RPH handler. The attacker can still navigate to the mailto
>> URL from one of the attacker's own pages, but can't do it from one of
>> the legitimate site's pages. So the attacker can't make it look like the
>> legitimate site is asking the user to send the confirmation email.
>
> How is the mailto: handler supposed to know who is legit and who isn't?
>
>
>> The important thing to understand here is that a communication channel
>> that is vulnerable to tampering can be abused in unexpected ways.
>
> You don't need to tamper with the communications channel as far as I can
> tell. If you can navigate an <iframe> as you describe, then even if the
> mailto: information is put in the path or query component it would still
> be possible to do the attack you describe. Just wait for the iframe to
> appear and then navigate it to the mailto: handler with the parameters you
> want. Since browsers only allow "tampering" with the fragment identifier,
> the simpler solution is to just not use the fragment identifier.
>
>
>> Rather than quibble about how a future attacker might make use of this
>> vulnerability in some future application, the right thing to do is
>> eliminate the vulnerability.
>
> I don't see how what you propose eliminates the vulnerability.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'