140064 - Long username/password parts of URL confuse user (not user

Status: VERIFIED DUPLICATE of bug 122445

(Core :: Security, defect)

Description

[Kai Engert (:KaiE:)]

Imagine a URL like:

  http://cnn.com/bla....[long]...@123.123.123.123/real-url/.....

The site fakednews.com is using that trick to make jokes and surprise people.

Many users would not recognize the site is not cnn.com, because they don't
expect the first part of an URL to be something else (a username).

Even experienced users may not recognize that immediately, because if the URL is
long enough, you don't see the @ char in the URL bar.

Mozilla should enable users to protect themselves against such malicious sites,
and give the user an easyly and immediately recognizable way to see the domain
the displayed page is coming from.

A discussion on the #mozilla irc channel produced some discussion. We would have
to make sure that long host names wouldn't cause a similar effect.

So my first suggestion, for discussion, is:

Let us reserve some space somewhere in the UI, which displays the last 2 parts
of the host name, or alternatively, the IP address.

This space should not be modifyable by any kind of JavaScript code.

We have multiple alternatives for displaying that toplevel domain info.
It should not be displayed inside the standard status bar area, because that can
be changed by JS. But we could reserve a small area in front of the normal
status bar text.

Another alternative is to add another read-only statusbar or toolbar, which
could be turned off by users who do not care.

An additional suggestion was to display warnings when people are going to submit
login data as part of an URL, to make them become aware of that - but criticism
was, users would click away that warning.

I'd prefer a bar that is permanently visible in the UI, and can be disabled by
users who don't want it for some reason.

In addition, the page info window should be enhanced, to not only show the URL,
but split it in more easily understandable chunks, like host, domain, url,
username, "used a password".

Comment 1

[Kai Engert (:KaiE:)]

The news are already reporting about that kind of trick, e.g.:
  http://www.spiegel.de/netzwelt/netzkultur/0,1518,193521,00.html

Comment 2

[Kai Engert (:KaiE:)]

over to security/general

Comment 3

[Ben Bucksch (:BenB)]

Page info enhancement is a good idea, but should be a separate bug.

I am in favor of something that triggers for urls with username only. That's a
unusual case, and evenin the legit case, users may want to be made aware that
they are submitting a username.

We have a problem with cutted hostnames in general, not just with usernames.
<windowsupdate.microsoft.com.querywithalongstring.thatpushestherealdomainout.malicioussite.com/installtrojan.html>
Both in the urlbar and the statusbar (hover over links). The latter is even
worse, because it cuts in the middle, not the end.

Telling me the host I am currently visiting might not be enough, because I might
not want to visit the site *at all*. (JS exploits, ad-popups, offending content,
whatever reason.) *Before* clicking on a link, I already have to be aware of the
host I am about to go to.

This hit the news already, for example:
<http://www.heise.de/newsticker/newsticker/data/se-10.02.02-000/> (in German)
<http://www.heise.de/newsticker/newsticker/data/wst-05.12.01-002/> (in German)
(Please add more URLs)

Comment 4

[Ben Bucksch (:BenB)]

There are exploits worse that fake news: A malicious site might trick you into
entering sensitive information like passwords etc..

Comment 5

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 122445 ***

Comment 6

[Ben Bucksch (:BenB)]

Reopening. THe other bug is specifically about usernames in hostnames. While
that was an important paprt of this bug, it is broader, as my example demonstrated.

Comment 7

[Kalin Kozhuharov]

Good that I knew this bug! I just got tripped by a link from:

http://www.fakednews.com/

http://www.cnn.com:443@212.190.116.226/news.php?DwDCo1pq

Comment 8

[benc]

Does this still happen? I thought we fixed a couple cases of this spoofing.

I've also moved the enhance page info comment to Bug 212327.

Comment 9

[Tim Powell]

It seems like it would be easiest to just omit the username and password in the
statusbar, or to place them at the end. Although there are uses for the
username:password combo, it seems more important to show the domain name.

So you'd have something like this in the statusbar:
http://123.123.123.123/real-url/... (username : password)

instead of
http://username:password@123.123.123.123/real-url/...

As Jesse Ruderman pointed out in bug 122445 comment 86 it might make sense to
url encode the username and password (convert dots to %2e, for example) so that
it is not easily mistaken for a domain name.

Comment 10

[Scott Plante]

This method of fooling users has been given the name "phishing" and has let
Microsoft to actually stop supporting usernames & passwords in http(s) urls. I
say that's a pretty extreme response and there are much better ways to handle it.

My suggestion is to replace the user id and password in the url bar with an
icon, that shows the actual user id and password as a tool tip. Also, when the
URL shows in the status bar when the mouse is over a link, you could just show
"user:[e-mail]" but actually show user:pass, not the real user and
password, perhaps in italics or something.

Comment 11

[Ben Bucksch (:BenB)]

usernames in URLs are discussed (over-)extensively in bug 122445.

Comment 12

[Scott Gifford]

This looks to me like a complete dup of bug 122445.  Feel free to re-open if you
disagree.


*** This bug has been marked as a duplicate of 122445 ***

Comment 13

[Ben Bucksch (:BenB)]

This difference is that this bug includes stuff like
windowsupdate.microsoft.com.update.evil.com, while the other bug only deals with
userpass, e.g. [e-mail].

Comment 14

[Ben Bucksch (:BenB)]

Actually, this bug is only about username as well, I must have imagined it.

verfiy dup

Comment 15

[Scott Gifford]

Right, Ben, the very long domain name issue is bug 233865.

Comment 16

[Juha-Matti Laurio]

Last modified in March 2004 and a dup, anything new..