[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Tyler Close]

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

The RPH handler doesn't need to know which is the legit site. The RPH
handler just needs to know that it's getting the RPH data from the
site that the user was interacting with, not some other unseen site
running in the browser. Putting the %s data in the window.location
lets an attacker overwrite it.

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

That's exactly right! The whole window.location communication path is
vulnerable to tampering, so we need some other way to communicate the
RPH %s data, such as a DOM field.

With appcache fallback, it's not necessary to use only the URL
fragment for an offline scenario to work, which makes talking about
the URL fragment in this scenario extraneous. Assuming the mailto RPH
handler is using appcache with a fallback, this whole scenario works
if the %s data is in the path or query. The problem is that the whole
window.location is a communication channel that is vulnerable to
tampering within the browser.

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

The vulnerability is that window.location can be overwritten by other
code running in the browser. For that reason, I'm proposing we use a
different channel to communicate RPH %s data from the client to the
RPH handler. I'm swapping in a tamper-proof channel for one that can
be tampered with.

That window.location is vulnerable to tampering is widely agreed. We
should be able to easily agree to not use it when we have a
tamper-proof alternative. This should be easy.

--Tyler