Closed Bug 140064 Opened 18 years ago Closed 16 years ago

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

Categories

(Core :: Security, defect)

defect
Not set

Tracking

()

VERIFIED DUPLICATE of bug 122445
mozilla1.4beta

People

(Reporter: KaiE, Assigned: security-bugs)

References

()

Details

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".
The news are already reporting about that kind of trick, e.g.:
  http://www.spiegel.de/netzwelt/netzkultur/0,1518,193521,00.html
over to security/general
Assignee: Matti → mstoltz
Component: Browser-General → Security: General
QA Contact: imajes-qa → bsharma
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)
Blocks: Beonex
There are exploits worse that fake news: A malicious site might trick you into
entering sensitive information like passwords etc..

*** This bug has been marked as a duplicate of 122445 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Depends on: 122445
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
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla1.4beta
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.
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.
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:pass@whateversite.com" but actually show user:pass, not the real user and
password, perhaps in italics or something.
usernames in URLs are discussed (over-)extensively in bug 122445.
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 ***
Status: ASSIGNED → RESOLVED
Closed: 18 years ago16 years ago
Resolution: --- → DUPLICATE
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. windowsupdate.microsoft.com@update.evil.com.
Actually, this bug is only about username as well, I must have imagined it.

verfiy dup
Status: RESOLVED → VERIFIED
Summary: Long username/password parts of URL confuse user → Long username/password parts of URL confuse user (not user
Right, Ben, the very long domain name issue is bug 233865.
Last modified in March 2004 and a dup, anything new..
You need to log in before you can comment on or make changes to this bug.