[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

>>> On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson <ian at hixie.ch> wrote:
>>> > On Mon, 26 Sep 2011, Tyler Close wrote:
>>> For example, a web mail program might have two registered RPH handlers
>>> for mailto: "https://example.org/?from=me at company&q=%s" and
>>> "https://example.org/?from=me at personal&q=%s". The user has configured
>>> their browser to send mailto links to their personal email editor. A
>>> malicious client page could directly open the URL for the company email
>>> editor. The web mail editor needs a way to detect when a client page is
>>> trying to subvert the user's chosen preferences. So, an RPH handler
>>> needs a way to know that it was loaded via the RPH dispatch. Once it
>>> knows this, it can also trust that the arguments in the URL, such as
>>> "from" in this case, were not tampered with by the client page.
>>
>> I don't understand the attack scenario. Sure, a Web page can open another
>> Web page with arbitrary arguments. Why does it matter here?

In the example above, the user is expecting that clicking a mailto
link initiates sending of an email from their personal email account.
The attack page bypasses the RPH dispatch and directly sends the user
to their company email editor. Consequently, the user sends an email
from the wrong account, with potentially embarrassing results.

With the change I am asking for, the mailto RPH handler can detect
that the RPH dispatch was bypassed and show UI that says: "Hey user,
this was an unusual request. Are you sure you want to use this
account? Maybe you want to use one of these others." In the legitimate
scenario, the mail handler page can assume that the user is using the
account they intended to, since the browser indicated that this is an
RPH request and so this handler is the one the user purposely
selected.

In other RPH use-cases, bypassing the user's selected preference could
have worse consequences. It's easy to protect against this and so not
have to worry about what else could go wrong.

--Tyler

Received on Friday, 6 April 2012 16:50:41 UTC