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
