W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Disallowing dots in the protocol argument of registerProtocolHandler()

From: Wilhelm Joys Andersen <wilhelmja@opera.com>
Date: Tue, 19 Apr 2011 15:51:47 +0200
Message-ID: <op.vt6t4lyqm3w6te@kunnskapet.oslo.osa>
Good afternoon,

When playing with registerProtocolHandler() last week, I noticed
that the following constructs are possible:

   navigator.registerProtocolHandler("mail.google.com",
     "http://evilsite.tld/%s", "Google Mail");

   navigator.registerProtocolHandler("192.168.1.1",
     "http://evilsite.tld/%s", "D-Link Wireless Router");

According to the URI spec[1], both "mail.google.com" and
"192.168.1.1" are valid URL schemes:

    "Scheme names consist of a sequence of characters beginning
    with a letter and followed by any combination of letters,
    digits, plus ("+"), period ("."), or hyphen ("-")."

After running the lines of script above, typing any of the
following URLs will lead the user to evilsite.tld:

    mail.google.com:80/mail/
    192.168.1.1:80

The use of confusing URLs to trick the user into visiting a
malicious site is nothing new. The difference this time is that the
URLs above would trick even me, and I'm not particularly prone to
phishing.

Using this technique to trick users would require an attacker to
bypass two obstacles:

   * To permanently add "mail.google.com" as a scheme pointing to
     evilsite.tld, user approval in two separate dialogs is
     required in both Firefox and my internal Opera build.

   * If the user's web browser keeps the address field visible
     at all times, the user may notice that they are redirected
     to evilsite.tld once the URL has been interpreted by the
     browser.

Despite this, we would prefer to err on the side of caution here.
Our experience with other warning dialogs indicate that users don't
necessarily read or understand what they approve, and phishing
schemes with far cruder URLs (paypal.com.evilsite.com) succeed
surprisingly often.

To save ourselves (and our users) from possible future headaches,
we have decided to disallow the use of dots in the protocol argument
of registerProtocolHandler().

Of the IANA-registered URL schemes[2], only the following contain
dots:

   iris.beep
   iris.xpc
   iris.xpcs
   iris.lws
   soap.beep
   soap.beeps
   xmlrpc.beep
   xmlrpc.beep
   z39.50r
   z39.50s

I don't see any clear use cases for overriding any of the above in a
web browser.

Opera will still interpret URLs in accordance with the URI spec, but
registerProtocolHandler() may only override the subset of URL
schemes containing alphanumeric characters, "+" and "-".

I suggest the same restriction is added to the HTML specification.

A proof of concept of the issue described in this email can be found
here:

   http://people.opera.com/wilhelmja/registerprotocolhandler/


[1]: http://www.ietf.org/rfc/rfc3986.txt
[2]: http://www.iana.org/assignments/uri-schemes.html

-- 
Wilhelm Joys Andersen
Core, Opera Software
Received on Tuesday, 19 April 2011 06:51:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT