Closed Bug 122445 Opened 23 years ago Closed 16 years ago

URL: Spoof - userpass looks like a hostname

Categories

(Core :: Security, enhancement, P3)

Product:
Core
Component:
Security
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7alpha

People

(Reporter: slice1900, Assigned: adamlock)

References

(Blocks 2 open bugs,
URL
)

Details

Attachments

(7 files, 3 obsolete files)

Mockup of URLbar with username/password entry
22.90 KB, image/png
Details
Mockup of alert idea
4.87 KB, image/png
Details
Simple HTML with example links
658 bytes, text/html
Details
The simplist way to provide trust between websites and users without breaking the web as we know it.
25.93 KB, image/jpeg
Details
Patch
7.37 KB, patch
Details | Diff | Splinter Review
Screenshot of styled page (this page, in fact) - no mockup
28.51 KB, image/png
Details
added pref("browser.urlbar.showUserPass")
42.23 KB, patch
Details | Diff | Splinter Review 
There are a lot of dodgy links on the net where someone will try to redirect you
to somewhere other than where you think you are going.  I saw the above link in
a story at The Register (http://www.theregister.co.uk/content/28/23859.html) and
according to the story, Opera will warn a user when it encounters such a link. 
That sounds like a good idea, Mozilla ought to steal^H^H^H^H^Hborrow it.

I'm not sure if you'd want to warn on every occurrance, perhaps it should only
warn when the "username" has one or more .'s.  Like some of the other security
warnings, it could include a checkbox to allow users to disable the warning if
they use HTTP authentication and has .'s in their usernames.

I filed this under enhancement, but it could be thought of as fixing a security
bug...
reporter: can you please summarize what mozilla does and what mozilla should be
doing?  thx!
Darin: 
If you open this link :
http://www.microsoft.com&item%3Dq209354@hardware.no/nyheter/feb01/Q209354%20-%20HOWTO.htm

you think that you are going to microsoft.com but you are on hardware.no...
cc'ing mitch for comment on the potential security impact of this.
Yeah, this is worth thinking about. It's basically a way to confuse a user as to
the meaning of a particular URL. I'm not sure how serious this is - I would say
not very serious but still worth fixing. Let's keep this bug, and assign it a
low priority.
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
mstolz:
I saw this link yesterday on IRC (#mozilla) but i realized today that I was not
on the microsoft.com server ! (You can think that I'm stupid but i know what
user@domain.com means)
What happens if I create my own banking page (use a nice CGI script: User enters
password on my page (looks identical to the real banking page)-> Server send
this password to the real banking site->Server gets Account informations from
the banking page-> Server sends this to the user.
I can steal money with this (transfer money to a bank on a little island)!

There are many users out there who don't know what user@domain.com means...
-> future, unless someone can convince me that we really need this by moz 1.0.
Priority: -- → P5
Target Milestone: --- → Future
From a corporate security perspective this is a great feature which we need
sooner rather than later.  Many hacker websites are put up each week and even
more emails to employees go out each week enticing them to go to websites that
have "obfuscated" URLs like
"http://www.OfficialCorporateSite.com@hackersite.org".  They trick people to
give up credentials, etc.

Clearly this won't solve the entire problem of social engineering, but getting
this fix in will raise the bar for the hackers.

Referring the poster's comments about whether or not to warn if there are so
many "."s in username: I agree, if the parser can also sniff out encoded
periods.  Strictly looking for the ascii character "." will be easily
circumvented by encoding it as %21 (or whatever the correct code is).
this is probably best solved in docshell's URI fixup code... necko doesn't have
any way of presenting a warning to the user during URL parsing, but docshell
could look at the URL structure after it is parsed to determine if it should
warn the user about this.
Assignee: darin → adamlock
Component: Networking: HTTP → Embedding: Docshell
QA Contact: tever → adamlock
URI fixup code only gets invoked when you type the URI into the address bar, not
when you click on something.

Do we have any kind of security mechanism already to veto whether a link should
be loaded or not?
We sure do - nsScriptSecurityManager::CheckLaodURI, which is due for an overhaul
anyway. Do you think we should add this warning to CheckLaodURI?
Makes sense to me :) Want to take it?

CheckLoadURI could have checks for this, hex encoded addresses and any other
scams you know of. In response it could display a security warning about an
unusual URL, perhaps displaying info about the real address the link points to.
-> Mitch
Assignee: adamlock → mstoltz
Component: Embedding: Docshell → Security: General
*** Bug 134371 has been marked as a duplicate of this bug. ***
My opinion is that you could add an option to show a warning when you are
opening an URL as user@domain.com but basically this syntax is correct and must
be allowed.
It's obvious, but it needs to be said. The pop-up dialog should clearly tell the
user what the warning is about. Possible text would be:

By loading this link, the browser will attempt to automatically login to %site%
using username %username% and password %password%. Do you wish to continue?
Continue, Cancel. Click here to disable this warning.
Keywords: mozilla1.0.1
*** Bug 137286 has been marked as a duplicate of this bug. ***
*** Bug 140064 has been marked as a duplicate of this bug. ***
Blocks: 140064
The warning doesn't have to be a dialog box. You could open an additional
toolbar, displaying the hostname, in these cases, or similar.
Oh, and "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." (from bug 140064).
Summary: Warn user if username encoded in link → Warn user if username/password encoded in link
Proposed relnote: If a username or password is embedded into a URI in the form
of http://username:password@sitename.com  Mozilla will not warn the user of this
when the user follows the link. URI's with long usernames in the form of
http://www.mozilla.org%2084230482304982304329048230948@fraudsite.com  could
deceive users into thinking they were going to mozilla.org when they were really
going to fraudsite.com.
Keywords: relnote
I don't think that this need a relnote.
This is a RFE bug and i agree with BenB that this doesn't need a relnote
It is technically RFE, but it is an important issue that could affect a lot of
users. 
minusing for 1.0.1. this is a feature enhancement and should be hashed out on
the trunk.
Keywords: mozilla1.0.1 → mozilla1.0.1-
Keywords: mozilla1.1
We could replace dots in the username and password with %2e as part of URL
canonicalization, eleminating the need for a dialog.  To be safe, we could also
escape other punctutaion, such as &, %, and $.  We do not need to escape ?, \,
and / because they already automatically end the username part of the URL, but
since they're not present in unescaped form, calling a function that escapes
them won't hurt.  We already escape = and space.  I think
escapeDots(escape(unescape(username))) would do what I want.
Keywords: relnote
Summary: Warn user if username/password encoded in link → Warn user if username/password in link look like a hostname
why did the relnote keyword get lost? I don't see any commentary about that.
Jesse: If I understand you correctly, you suggest, that whenever we see a link,
we should escape that link fully. At least we should fully escape username and
password. This escaped version should be displayed wherever the link gets
displayed, i.e. when hovering a link the string shown in the status bar should
be the escaped version, when you do "copy link location", when you use "view
page info / links". In addition, when you click the link and the new page has
been loaded, the URL displayed in the URL bar should also be a fully escaped
version.

This sounds like a good idea to me. The information shown would no longer look like:
  http://www.mozilla.org&fakefakefakefakefake.....
but like:
  http://www%2emozilla%2eorg&fakefakefakefakefakefake.....

Do we agree this would be sufficient to avoid the confusion on the user's side?

and our http code already automatically unescapes the username and password
before encoding them in the Authorization header.  seems like a good suggestion
to me.  perhaps it would be sufficient to simply modify the escape table in
nsEscape.cpp.  that should work, however, i seem to recall that there is some
unescaping done in the status bar when hovering over a link.  we'd probably have
to touch that code to make it not do that for the username/password, i guess.
... but be aware of issues with escaping already escaped urls again ... 
While it might help to have the dots show up as %2e, how many of your average
users (I'm thinking more of Netscape's audience than Mozilla's) will understand
the significance of this?  Sites like hotmail that make use of long URLs with
encoded information have trained users that the contents of the URL bar is often
gibberish. When you visit an external site, hotmail uses a numerical IP in the
URL, even users hip to the significance of www%2emozilla%2eorg may not notice
207%2e200%2e81%2e215.  It is just too much to expect of end users to read the
URL bar after each and every link they click on to be sure it is the site they
intended.  How many of those reading this do so?  I know I sure don't!

What is needed is a dialog that a login/password are being used to access
site.domain.com, showing the username and password, with an OK and cancel
button.  Under certain circumstances (login name contains '.' or '%2e' or is
longer than x characters or whatever) a message might be added that this could
be an attempt to misdirect you and recommend hitting cancel unless you are sure
you know what are doing.  Perhaps cancel would be the default button instead of
OK in such circumstances.  Having a gibberish username confronting you, along
with a recommendation that you shouldn't go on unless you are sure you know what
you are doing is far better.
 
Ben is definitely right in comment #20, the user should know this BEFORE he
visits the site, due to the possibility that the destination site could make use
of various exploits or tracking bugs that may be uncovered down the road. 
Relying on the user to see something odd in the URL bar, or notice some
additional read-only status bar isn't sufficient, and those ideas shouldn't be
considered IMHO, as they will only reduce by a very small amount the number of
people affected.  Even a dialog box won't eliminate the problem 100% because
some people may sleepwalk their way through and click OK without reading, but
then at least we can say we tried :)
> What is needed is a dialog that a login/password are being used to access
> site.domain.com, showing the username and password

A dialog for each URL/host with a username is a bad idea, because one webhoster
here in Germany sells website addresses which looks like email adresses as
feature, e.g. "joe@average.com" = <http://joe@average.com>.

I am generally reluctant to add any dialog, unless we are about to do something
really dangerous.
The only difference we display between a SSL and a non-SSL site is a little lock
icon in the lower-right; I don't see why a site with a username/password should
get anything more; probably less.

The point was to prevent people from seeing
  http://windowsupdate.microsoft.com/yadayadayada/yada/yada/whatever@yadayadayada/
and assuming it is actually windows update.

A dialog is a major overkill! It seems that just displaying any user name and/or
password from a link urlencoded would fix the problem, no?
http://windowsupdate.microsoft.com/yadayadayada/yada/yada/whatever@yadayadayada/

_is_ windows update.  the '/' after windowsupdate.microsoft.com takes precedence
over the '@'.
Re: Ben's comment #32

Mozilla already has a number of "annoying" dialogs like the ones you get when
you enter/leave an SSL site, with a checkbox you can uncheck for showing that
warning again in the future.  This would be a prime candidate for such a
warning, since the vast majority of web users will rarely or never visit a site
that legitimately uses an '@' in the URL or has a login/password.  But for that
minority who do, it would be easy to disable such warnings.

I guess I disagree with your implied contention that this isn't "dangerous".  It
is more of a risk that than submitting a form, which generates a warning dialog
until you disable it.  It is arguably equal to the risk involved with
entering/leaving an SSL site, since then at least you have the nice little lock
icon most users have been trained to glance at for a very simple indication of
whether or not they should be able to safely send credit card information or
whatever.  Other than HTTP authentication, which doesn't see a lot of use
anymore, or oddball sites like the German hosting one you mention above, most
times this happens to an end user, it will be deceive them, possibly with
malicious intent.
Hundreds if not thousands of popular pay web sites use redirect urls with an 
embedded username and password in to quietly transfer htaccess credentials from 
one subdomain to another.  If you set the default to alert people every time 
they hit one of these, you will confuse most consumers and cripple all of these 
web sites.  If you must pop up a warning dialog at all, I highly recommend that 
you not do it unless there is a high probability of confusion, such as dots in 
the username or password.

IMHO the potential for harm to the user outweighs any minor inconvenience
suffered by users of sites that have user:password@domain.com conventions. If
the dialog is worded in plain terms and has a checkbox to disable further
appearances, I don't see much of an issue. It certainly won't cripple these
sites any more than the https warning does for ecommerce sites.

> It certainly won't cripple these
> sites any more than the https warning does for ecommerce sites.

Please don't argue to add a problem by citing another one. The https warnings
are annoying, poor and even dangerous, if they lower users' regard to important
warnings.

If you pop up a dialog at all, please do it only for stuff that looks like
deception, e.g. more than one dot in username (one dot in username is normal,
like ben.bucksch).
Adam,
   I agree with Ben on this - warning dialogs don't really improve security in
most cases. Let's try to find a solution that doesn't involve a dialog - how
about some kind of smart URL viewer that breaks down a URL into its component
parts in an easily readable way? How about we just put the actual hostname in a
different color in the URL bar?
I guess I don't understand why it should be a problem to have a warning dialog
when you get a username/password pair that is masquerading as a domain.  Given
the examples cited in several comments, I fully accept it isn't reasonable to
warn on every use of http auth.  But as I suggested in my original comment that
opened this, warn if you have something that looks like an IP address (4 octets
separated by dots) or domain name (at least one dot followed by 2-4 letters then
you warn.  This won't affect goofy domainnames with @'s in them, or 99.99% of
valid http auth still in use.  You include the checkbox to disable the warning
just in case it really does affect someone's legitimate use.

While I like Mitchell's idea of the color coded URL bar (putting the http auth
stuff in red would certainly attract the user's attention) it has two problems.
 One, it only warns you after you've arrived at the site.  Two, while the user
may figure out that the bright red color in the URL bar means something, it'll
be hard to figure out what it means, or that it means the current page shouldn't
be trusted.  If this appears on an SSL site masquerading as the user's bank web
site, he might think the brightly colored URL bar is a recent addition to
highlight the fact that the page is indeed secure!
Keywords: mozilla1.1 → mozilla1.4
Users should not be relying on a hostname or a URL to authenticate a site
anyway.  This is why we have SSL certificates.  If we agree that there is a
security problem we need to solve (even if it's psychological), maybe we should
consider solving it a little further "upstream" than this.  I don't think we
should encourage sanity checks of URL's so much as sanity checks of a site's
identity.  Bug 184881 takes a step in this direction, but might be a bit radical
for the near term.
As of today, when the URL is longer than the visible area of the URL field, we
display the leftmost portion of the URL.

What if we displayed the rightmost portion?

> Users should not be relying on a hostname or a URL to authenticate a site
> anyway.
Agreed, and in the long term we should be working to educate users about this.
However, for now, many users look to just one place to verify the site's
identity - the URL bar. So, we should at least raise the bar on spoofed and
misleading URLs.

I still think we should go with some kind of color-coding scheme, coupled with
some user education in the form of release notes and webpages. That's
informative without intruding on the user experience like a dialog.

> Mozilla already has a number of "annoying" dialogs like the ones you get when
> you enter/leave an SSL site
That's all the more reason why we should not add another. There are lots of bugs
for which we could add warning dialogs, and I almost always argue against it.
It's a slippery slope - we could warn the user about a lot of things, and they'd
get so many dialogs it would look like a pop-up ad blitz.

> it has two problems.
> One, it only warns you after you've arrived at the site.
There's no way to avoid that. A page can *always* disguise the target of a link
before the user clicks it, and there's nothing we can do. As Jesse R. pointed
out to me, a script can change the target of the link when you mouseover it, so
that something else appears in the status bar, then change it again when you
click. Or the link could just point to a redirector. There's no way for us to
prevent either one.

> Two, while the user
> may figure out that the bright red color in the URL bar means something, it'll
> be hard to figure out what it means,
There's an education component here. Coloring the URL parts will make the parts
visually distinct from each other, and that will help keep a reasonably
competent user from making a careless mistake. A naive user may not get it, but
then most naive users, when presented with a dialog, will either blindly click
Yes or else say "IE never gives me this dialog, Mozilla must be defective."

Kai's suggestion is a good start.

read my lips - no new dialogs.
What happened to my suggestion from comment 26 to escape puntuation (. as %2e,
etc.) in usernames/passwords displayed in the URL bar?  I don't understand why
we're still debating whether there should be a dialog to warn about misleading
URLs when we can make a simple change to URL canonicalization to prevent
usernames from looking like familiar domain names.

In comment 42, Kai suggested showing the rightmost portion of the URL when not
all of the URL can be shown at once.  I don't see how that would help, since
hostnames are almost always at the beginning of the URL.

Coloring parts of the URL would be cool, but I think it should be a separate
bug.  It would only work in browsers that use Mozilla's URL bar and it could be
controversial or hard to implement.
> What if we displayed the rightmost portion [of the URL]?

This bug is about the fact that the hostname is hidden. What you suggest means
that it's almost always hidden, given the small URLbar in the default config and
usual display resolution / browser window size. :(

If you want to go that route, I'd make sure that the right part of the *domain
name* is always visible.

> Or the link could just point to a redirector.

Then I would already have clicked on a link to an untrusted site ;-).


I like jesser's suggestion.
I'm not sure that escaping punctuation would be any more effective than
color-coding...I think we need a UI expert.
If usernames are red and hostnames are blue, and the user suddenly sees the
hostname in red instead of in blue, what would he think? I guess he wouldn't
know what to think. With escaped punktation, it doesn't look like a hostname at
all, it just looks freaky.
> With escaped punktation, it doesn't look like a hostname at all, it just looks 
> freaky.

In particular, it doesn't look like a hostname the user might trust, such as
www.microsoft.com.  Which, IMO, is what's important.
What about putting some sort of localized in-line popup next to the URL? For
example, the stream converter could insert an animated warning icon by the
suspect URL and when the user mouses over the URL or the icon, a warning appears
in a tooltip or dropdown to explain the URL might be dangerous.

as it sounds silly, i am saying that dialog box is in place here. user can
always dismiss it, if he's savy enough, but average user NEEDS some feedback.
just the suggested wording should be changed to something like

Mozilla has detected that you are attempting to visit a spoofed site.
Link you clicked or entered is not leading to site <username> but to the site
<hostname>. While majority of such sites are created for humor purposes,
visiting one might also be a security risk. Continue to the site anyway?
<continue> <cancel>
[] do not warn me again for this username (or site, but i prefer username, not
site checking)

sometimes the most obvious solutions are the best. user-wise. 

ok. the next one should be mozilla automatically recognizing Kings of Chaos and
Outwar links nad disabling them:P
Better ways to do this than an annoying dialog:

   - In the status bar, when hovering over http://www.cnn.com@www.evil.com/,
     display this instead:
         [www.evil.com] http://www.cnn.com@www.evil.com/

   - In the URL bar make sure the actual hostname is on screen, by scrolling
     if necissary. If there is a username, hilite the actual host name by
     making it a different color, a different background color, or a different
     style (e.g., bold). Alternatively, emphasis could be put on the
     username:password@ portion by putting it in italic or slant.

I think these are the main two places people might get confused by URLs with
usernames in them. And I think it solves the problem without any annoyance.
*** Bug 211934 has been marked as a duplicate of this bug. ***
*** Bug 212296 has been marked as a duplicate of this bug. ***
I'd like to make one comment for a dialog box solution (yes I have read the
entire bug).

I don't think fixing status will work, because of Jeese's mousover js still
works, and I don't think color coding the URL bar works either, because it is
too late.

The dialog box is idea, to me, because you should think about the combination of
two factors: 

1- cost of increasing "annoying" dialog boxes"
2- relevancy of warning.

As the URL parser tester (and having done some system administration and DNS
administration off and on for almost a decade), there should be very few links
were people are legitimately using URLs w/ usernames, much less usernames w/ dots.

So this warning would, in a normal world, appear almost never.

In the real world, I cannot think of any other interpretation of the authors
intent when I see a URL like this, except that they are trying to trick the user
by spoofing the apparent display of the URL. One of the duplicates points out
that this trick works w/in HTTPS, the SSL lock will appear (since the hostname
necko users does match the hostname in the cert).

I think the user needs some clear explaination for what is going on, why they
would not want to proceed, and what the point of possible confusion is.

Additionally, it occurs to me, that in response to Jeese's URL link spoofing, we
 might also consider some kind of security feature where javascript triggered
from an HREF that loads a different URL than expected should provide a similar
warning.

Otherwise, I agree that we have alot of annoying dialogs, but that does not mean
we should stop using dialogs to warn people about real problems.

spammers are starting to hang more w/ hackers and virus writers, so I think
spoofed email w/ a spoofing link is going to become much more common in the future.
benc wrote:
> this warning would, in a normal world, appear almost never.
> In the real world, I cannot think of any other interpretation of the
> authors intent when I see a URL like this, except that they are trying
> to trick the user by spoofing the apparent display of the URL

Comment 32. That mentioned hoster is huge (IIRC Schlund), with a few million
domains, but I don't know how popular that particular feature is.

> we might also consider some kind of security feature where javascript
> triggered from an HREF that loads a different URL than expected should
> provide a similar warning.

Unfortunately, JS abuse like <a href="thispage.html"
onclick="javascript:location.href='someotherpage.html'"> is extremely common on
legitimate sites (often with href="." or href="#", though), so we can't do that.

>Ispammers are starting to hang more w/ hackers and virus writers, so
> think spoofed email w/ a spoofing link is going to become much more common
> in the future.

heh, just happened today <http://www.heise.de/newsticker/data/ju-10.07.03-000/>.
>Comment 32. That mentioned hoster is huge (IIRC Schlund), with a few million
>domains, but I don't know how popular that particular feature is.


So what?  That's ONE hoster.  That's going to be a tiny portion of Mozilla's
userbase.  Let them disable the dialog if they get annoyed by it, all the rest
of us can be just a bit safer from those with nefarious intentions.

Besides, its irrelevant.  If Mozilla is smart enough to know that
"http://joe@average.com is going to the domain joe@average.com and not
average.com, the dialog won't be trigged anyway.  And my original suggestion
when I filed this bug was that it only flag usernames with .'s in them which
wouldn't affect this hoster's goofy domains anyway.

I can't believe something so simple has been ignored, particularly due to bogus
objections involving one web hoster few if anyone outside of Germany has ever
heard of.  Build the Deutsch versions of Moz with this disabled or something,
sheesh!
> So what?  That's ONE hoster.

Yes, one of the biggest in the world ;-). My point (in response to benc) was
that there *are* valid uses, and they don't appear "almost never". Too often
that a dialog is troublesome? I don't know.

> If Mozilla is smart enough to know that "http://joe@average.com is going to
> the domain joe@average.com and not average.com, the dialog won't be
> trigged anyway.

It *does* go to domain average.com. "joe@average.com" is not a domain.

> it only flag usernames with .'s in them which
> wouldn't affect this hoster's goofy domains anyway.

Email usernames do contain dots. <mailto:anne.freida@benning.com> ->
<http://anne.freida@benning.com>

> sheesh!

No more popups, sheesh! ;-)
Ben: I've given this a lot of thought this afternoon, and I don't even think of
it as a security issue anymore. There is a lot of compromising and interelated
issues that make security design (at least to me, a big headache) Jesse's
objection was really powerful, it basicially had me convinced that this was an
unsolvable problem, that you can never trust what you click is what you get. It
finally occurred to me that javascript could also be compelled to behave
properly as well.

I've realized that this is more of an honesty issue which resides at the level
of "how are people going to handle acessing Necko URL parser", which is
basically that as components call necko, they should be able to progamatically
see what is the likely user FQDN, and compare that with what FQDN they actually
go to. If there is a likely case for confusion that could be substantial, then
warn the user.

As for there being one big site that is the exception to my exception (they
really do this, but don't indend to deceive), well after we fix this, we can
send them to evangelism :) 

At that point, it really comes down to good judgement, there are lots of things
in life you can do, but really shouldn't. In this case, our browser would pass
judgement on their URLs, and deem them bad, for what I think are pretty good
reasons.

I'm going to stretch a little bit here too, and suggest that we need to be
staying ahead of spammers, rather than let them keep dragging us through many
fire-drills where they were clever and we were careless.
> Jesse's objection was really powerful, it basicially had me convinced that
> this was an unsolvable problem, that you can never trust what you click is
> what you get

Yes, currently, but you should be able to. If you can't, this is a design bug
IMHO. I must be able to know where I am going and not have to trust the linking
site. Filed bug 212375.


[Schlund's <http://joe.s@average.com> websites]
> we can send them to evangelism

OK with me, although I found their idea quite creative :).
*** Bug 212999 has been marked as a duplicate of this bug. ***
I like the idea of coloring a part of the URL and scrolling it so that the
domain name is always visible, but instead of coloring the Username/password
(which would only be there sometimes), why not color the domain name all of the
time?  Then users could get used to seeing the domain of the site in say, bold
and blue, and if a malicious URL was entered they could see easily that they are
at a weird site.  This wouldn't solve the security problem totally, but it would
be less confusing than all the sudden seeing color in the address bar.  Just my
2 cents...
The problem with this is that by this time it may be too late, if the page is
malicious (taking advantage of a browser bug or downloading a bad file -- if
someone thinks they are downloading the latest MS security patch, but are really
downloading Back Orifice or its ilk...)

And even if people get used to see colored stuff in the address bar, its still
something that wouldn't be noticed all the time, or even most of the time,
except by those who are very paranoid.

If people are that dead set against a warning dialog for the specific rare case
(username with .'s in it, not every username/password instance) that most people
will never see even ONCE and can be easily dismissed forever with the checkbox
like other security warnings for SSL, etc. then maybe a tooltip that pops up for
these occasions when you move over such a link?  It wouldn't be as intrusive as
a dialog, but would give the warning before someone clicks on the link, instead
of after it is too late?  If you move quickly it'd just flash there and wouldn't
be noticed, especially if you leave tooltips on and are used to seeing them
everywhere.  But while not nearly as good as a dialog, it is still better than
nothing, and better than showing you've already been fooled or 'sploited after
the fact via the addressbar.
Why not use some rules of thumb? Like, maybe, if the username+password part is
longer than X characters OR (is longer than Y characters AND contains more than
Z url-encoded characters) OR (username part looks too much like a popular domain
AND there are more than K url-encoded characters after that)... then issue a
warning (with a Don't Warn Me Again checkbox)
Here's an example of this being used to scam people.  See:

http://www.theinquirer.net/?article=11081

A spam is being sent purporting to be from citibank, the URL starts out with
www.citibank.com with a random string of letters and numbers (which people
expect since it is used for many session based web sites) and way off to the
side the @ is used to invalidate that part and hand you off to a scam site that
attempts to grab your credit details.

With my suggestion of alerting users when a "username" that contains a '.' is
used that this is likely something nasty anyone clicking on that link would be
safe (assuming the warning is stringent enough and the default of the pop up
message isn't "OK")

It can be argued that anyone dumb enough to fall for this deserves what they
get, but think that while anyone reading this would know better, can you say the
same thing about your parents/grandparents/(insert computer illiterate friends
or relatives here) ?
I saw a similar one recently -- an HTML mail where the text of the link was a
normal paypal URL, but the actual HREF was to some other site. If we're checking
for suspicious links should we at the same time warn if the text of a link looks
like a URL but does not match the actual link (or even just check the hosts)?
Summary: Warn user if username/password in link look like a hostname → Warn user if username/password in link (url) look like a hostname
Re: comment 64 - see http://news.bbc.co.uk/1/hi/business/3217485.stm to see
"phishing" hit mainstream news. The scammers are using spam lists, so are
hitting lots of novice users. It would be a big win (and big "selling" point)
for Mozilla to implement a scheme to make the user properly aware of the domain
a link is taking him/her to.

Two things could be done:

1. Note the user when the target domain is not expressed in cleartext, e g:
http://www.kuro5hin.org:section@1109654166/ (from a post at slashdot).  I can't
see a situation where it is a non-fraud need to use such a format.  (With the
exception that some sites use the dotted format of the IP address
(123.456.789.321) when pointing to some files.  But I think that's unusual and
very temporary uses.)

2. Always display the name of the site you are at.  That is when you have
followed a link as those we are discussing here and at the resulting site still
have something like
http://www.mozilla.org%2084230482304982304329048230948@fraudsite.com/ in the URL
field we should make it obvious that the user are at fraudsite.com (maybe by
displaying [fraudsite.com]
http://www.mozilla.org%2084230482304982304329048230948@fraudsite.com/ in the URL
field).
1. Display a warning dialog:
 1a) when going to a URL with a username that contains '.'.
 1b) when going to a URL with a long username.
 1c) when going to a URL with a username.

2. Modify how the URL is displayed:
 2a) Color passwords differently from domain names.
 2b) Don't display the username and password in the address bar.
       http://www.mozilla.org:crap@ebay.com/
       ->
       http://ebay.com/
 2c) Put the name of the site before the URL when there is a password.
       http://www.mozilla.org:crap@ebay.com/
       ->
       [ebay.com] http://www.mozilla.org:crap@ebay.com/
 2d) Escape the password when canonicalizing http URLs.
       http://www.mozilla.org:crap@ebay.com/
       ->
       http://www%2Emozilla%2Eorg:crap@ebay.com)/

3. In addition to having the address bar, display the hostname somewhere else in
the UI (bug 140064 comment 0).

Of these, I prefer 2b or 2d.
Whiteboard: spoof
1d) when going to a URL with a username which contains a dot and is a valid
domain name, for that do a DNS lookup before displaying the dialog.
(I don't think that exposure of the username to DNS servers is a problem for
HTTPS and not at all for HTTP.)
Rationale: Prevent spurious warnings, DNS looksups are hopefully faster than a
user interaction and also less annoying. If it's a valid domain, the likelyhood
of fraud is high, so a warning dialog is appropriate.

2e) Display username/password in grey, maybe don't show passwords in cleartext
at all, adjust alignment of URL so that as much as possible is visible from the
right part of the domain name.
More grist for the mill.Fixing this would be a big PR win for Thunderbird / Moz
Mail. I believe priority on this should be at least 3 if not 2.

http://news.netcraft.com/archives/2003/10/26/customers_of_uk_banks_and_brokerages_attacked_with_new_wave_of_fraud_and_theft.html
I continue to be astonished at the reluctance Mozilla's developers have to fix
this problem.  I opened this nearly two years ago and nothing has been done at
all, it isn't even targeted.  I wish the codebase were understandable without
days or weeks of work learning it so I could code the damn thing myself, maybe
it'd get accepted if it was already done and ready to go.

Do even 1% of all browser users use name/password authentication at all?  Do
even one of 1000 of those use usernames with .'s in them?  This is so easy to
fix with a simple confirmation box that would alert clueless users being spoofed
about it.  I bet well under 1000 Mozilla users would ever have to click the
checkbox to disable future warnings.  Anything you do in the URL bar will NOT BE
NOTICED by the average user.  Why do you guys want to target your fixes at
technically competant users?  We aren't the ones who will be successfully
spoofed anyway (or even believe that our bank would email us asking for a
"confirmation" of our password, SSN, etc.)

Is "one more dialog" really a concern here?  Honestly, Mozilla still defaults to
putting up a goddamn warning if you do something ever so dangerous like
SUBMITTING A FORM!  But spoofing isn't worthy of a warning?  Get rid of the
retarded warning about submitting a form and replace it with this warning, then
there are no more net warnings added to the browser, but the ones that are there
are more useful.

Maybe we just have to wait for Longhorn before this is fixed in Mozilla.  Once
IE handles this problem (and I'll bet they do) Mozilla will be scrambling to
follow, when it could have taken the lead in security instead of being a
follower behind Microsoft (how embarressing)
I have to agree with the previous poster. I have found nothing but resistance to
getting things fixed/improved/added to mozilla. If you want people to treat
mozilla with respect, then the main developers need to treat their users with
the same respect. 

As long as legitimate requests keep being piled in the 'too hard' basket, or the
"we shouldn't do that, but I won't offer a better alternative" basket, or the
"I'm not going to do that because I said so" basket, Mozilla will never become a
leader in the browser market, and will be forced to play catchup with IE every
time they 'innovate' a new idea that will most likely have been stagnating for
years in a bugzilla entry. 

Hell, I wouldn't be surprised if microsoft got some of their ideas from here in
the first place.
Apologies for the bugspam.  Ian, slice:
The baskets and reluctance mentioned don't exist.
There are, I believe only around 8 people paid to work on Mozilla.  When you
whine about them not fixing your pet bug, you take away from the time they have
available to fix bugs and keep mozilla.org running in the first place.  I'm
pretty sure I have been guilty of this in the past.  Take a look at some of the
bugs that ARE getting fixed in each release, to gain some perspective.
If you want the bug fixed, then fix it.  If you're not willing to fix it, pay
someone, or otherwise help mozilla have resources to fix it.  If you won't do
any of those things, please stop complaining.  I don't think this bug needs any
more comments for now, unless they're from someone willing to write code. If you
must flame me/reply, don't do so by posting another comment.
Keywords: mozilla1.0.1- → helpwanted
Priority: P5 → P3
I'm just a dedicated, loyal Mozilla user, and I don't understand all the
technical details involved.  But for these trick URLs that look at first glance
like they're going somewhere other than the real destination, I'd like the
browser to tell me that all is not what it seems.  I'd like to see both a dialog
and a tooltip, both of which can be disabled if not desired.  With a tooltip to
alert me of a possible trick URL when I mouse over it, I could pass up clicking
on it to begin with.  The dialog box could let me know what destination the URL
is actually going to take me to, and give me a chance to rescind my click.  And,
considering that a lot of new users might be wooed to Mozilla, seeing how much
superior it is to the obsolescent monopoly browser, I'd recommend that these
options be enabled by default, with an obvious way to disable when invoked.

The suggestions for a colored or bolded segment of the URL in the location bar
doesn't appear to me to be of any use.  As was mentioned, by this time you're
already there, and though Mozilla is not the welcome mat for malware that IE is,
there still may be many reasons for not wanting to have gone there.

reseting milestone, in case anyone is following milestone triage.

adam: I'm going to take qa of this bug if you don't want it, following my
comments above.

darin: per comment 9 and 10, could you give an opinion on where this code would
need to be placed? If possible, please consider my arguement #54 that this
should not be as much a security feature as a URL parser feature. (I do not know
enough about necko internals to know if necko can generate warning dialog boxes,
so if I'm proposing something bad, please be kind when you say "no".)

slice1900 and Ian: This bug has 26 votes. I looked at # of bugs w/ 25 votes or
more, and I found 273. This is not to say that I disagree with you on the
technical merits, but that there is a lot of stuff going on. And there is a lot
of fixing going on, but there is always more stuff.

To build off Matthew's point, there are also lots of things you can do to help,
even if you don't code. Documenation, bug management, helping other people w/
their stuff, etc. With some 1 million odd downloads, mozilla does not need more
users, it needs contributors (that find other contributors). 

Pretty much everything that can be said about this bug has been said. If that is
the case, what are -you- going to do next? If you cannot repeat the same points,
if you cannot directly type something here to get the bug fixed, what can you
do, perhaps indirectly, not immediately, that will increase the chances of
getting this fixed? Are there skills you can share with others in the community?
Are there subjects you can learn more about to understand this problem better?
Target Milestone: Future → ---
The dialog box is the only way to prevent users from being spoofed. Coloring the
address bar won't work, because by the time the user sees the colored address
bar, the user is already victimized. By then, the user has already gone to the
spoofed site.

The dialog box would have a checkbox to disable it. Additionally, we could
implement a whitelist of all domains on which to never show the dialog box. That
way, users could still go to their username/password sites for admin purposes
without being hassled while still getting the benefit of spoof prevention
elsewhere on the Web. We don't need a pref panel feature. The technies will just
go to about:config anyway.

Either fix this with a dialog box or mark it WONTFIX. 

Summary change hopefully an improvement.

Would be great for 1.6. Here's for luck.
Flags: blocking1.6?
Summary: Warn user if username/password in link (url) look like a hostname → Spoof prevention: Warn if username/password in link (url) looks like a hostname
>The dialog box is the only way to prevent users from being spoofed. Coloring the
>address bar won't work, because by the time the user sees the colored address
>bar, the user is already victimized. 

What do you mean by "already victimized"?  Mozilla's job is to avoid letting a
site appear to be something it is not.  Mozilla's job is not to guess which
sites are malicious and warn the user against going to them.

>By then, the user has already gone to the spoofed site.

If the site fails to spoof itself (thanks to Mozilla escaping the username, not
displaying the username, coloring the domain name, etc), so what?
I vote for the dialog box, as per Andrew's specification at #76.
Attached patch Prototype (obsolete) — — Splinter Review 
This is a prototype demonstrating one way you might implement this. The
webshell file handles link clicks so I have inserted a check for dubious
things. URLs containing passwords with dots, "www", "com", "paypal" and a few
other checks cause the dubiousness to rise. If a link is sufficiently dubious,
the webshell poses a warning dialog.

The dialog needs fixing up (should we show the URL when they're typically very
long in these scams?) and a checkbox tied to a persistent pref, but this is
just a proof of concept.

The code should probably only fire for mail/news, but the appType setting on
the docshell was not set so I commented that test out. There might be some
other way to test this.

Also, perhaps the code shouldn't live in webshell. There is already some dialog
posing code in webshell so it doesn't add much bulk, but perhaps the
functionality should be farmed out into a component somewhere such as URI
fixup.

If someone wants to pick this up and improve it please do
Flags: blocking1.6? → blocking1.6-
Would it be a good idea to just turn following username:password@host links off? 
Let there be an option in Preferences to enable it for those users that 
understand what they are doing.

I am a freelance computer engineer. I have tested the Opera browser with a 
customer of mine and she *did not* understand Opera's "you are about to go to an 
address containing a username" dialog. In fact she says she just dismisses all 
dialogs because she doesn't understand any of them.

Also I believe none of my hundreds of customers ever need to follow links like 
this. My evidence is that I have set up hundreds of recent copies of Opera in 
people's homes (before Mozilla became my preferred and recommended browser). 
None have ever mentioned ever seeing this dialog.

I have just received a fake email purporting to be from Natwest Bank and it 
upsets me greatly that right now there is nothing effective I can do immediately 
to protect my customers against this danger.

How about a dialog saying:

Title: Fraudulent address alert
Icon: Big red STOP sign
Content: Mozilla has detected you may be about to go to a fraudulent address. 
The actual hostname in the address is [specify hostname]. For your protection, 
Mozilla has disallowed this potentially dangerous action. For further 
information, click [here]. 
Buttons: OK

The user will have to read the further information and then go into Preferences 
to enable following this type of link. By all means Mozilla could optionally be 
clever and attempt to detect misuse of this type of link. Surely this is 
subsiduary to allowing that type of link at all?

I am worried that Natwest and other banks are right now asking Microsoft to 
implement something like this in Internet Explorer. Then the banks will come down 
with a blanket policy like "NO browsers other than Internet Explorer and only 
then Internet Explorer with such-and-such patch". Then with my favourite browser 
shut out I will be very upset indeed!!

Phil Jones' comments were quite true. IMHO, we should consider the following
before making a dialog:

1. People don't read. The vast majority of users click OK without reading
anything else.
2. People are ignorant. They do things without thinking. (Examples: #1, using
IE, etc.)

We must make it semi-challenging to go to such a site. That way, ignorant people
are protected.

Jones' suggestion seems to fit the bill:
1. Disable the http://user:pass@whatever.com links by default. Should FTP links
of this sort will be blocked too?
2. Leave an option buried in the preferences to enable the links (for advanced
users)
3. The dialog features only an OK button. Manually opening the prefs to change
the settings shows you genuinely want to enable the links.
Disabling passwords is going to cause problems for subscription download sites
Sites such as fileplanet.com offer links for downloading games, mods, patches.
Anyone using this or a similar service may discover it doesn't work anymore in
Mozilla. Sun & Apple ADC also use strange temporary user/pass URLs for
controlling file downloads. They can't be the only ones.

I also don't believe that you can say with certainty that a link is fraudulent.
You can certainly make the dialog suitably eye catching with a big warning icon
and a plain English description of how it *may* be fraudulent. Users only have
themselves to blame if they ignore the warning.

I have modified my suggestion based on Ben Bucksch's comment (# 38). If the address contains a dot in the username part, or a dot in the password part, I suggest Mozilla should refuse to display the page. Even a single dot is exploitable with high-value sites that leave off the leading 'www', Slashdot style.Mozilla should of course explain why and offer a link to docs explaining what may be going on, and how to change this restriction. This will:Allow:http://joe:joepass@legitimatehost.comDisallow:http://bigbank.com/e-banking:update.html?Session=rdklk324342AAd&ClientIP@64.174.108.131/Sites with a reason to use dots in the username or password part must accept (IMHO) they are broken because criminals have discovered how to steal people's money via the Internet. To work around this, I suggest a browsing preference:Preference title: When a potentially misleading address is detectedOption (default): Do not go to the addressOption: Display a warningWhen triggered, the warning could look like Opera's dialog but with a bit more explanation:Title: Address contains a usernameIcon: AlertMessage: The address contains a username and/or password. Please be sure that the server name shown below is what you are expecting. If not, this may be a misleading address.  Server: 64.174.108.131Are you sure you want to continue? If you are unsure, click Cancel.Options: OK, CancelCheckbox: Do not show this again for this address
Sorry about my previous post which didn't seem to come out right. I hope you 
don't mind if I post it again.

I have modified my suggestion based on Ben Bucksch's comment (# 38). If the
address contains a dot in the username part, or a dot in the password part, I
suggest Mozilla should refuse to display the page. Even a single dot is
exploitable with high-value sites that leave off the leading 'www', Slashdot
style. Mozilla should of course explain why and offer a link to docs explaining
what may be going on, and how to change this restriction. This will:

Allow:
http://joe:joepass@legitimatehost.com/

Disallow:
http://bigbank.com/ebanking:update.html?Session=rdkl4342AAd&Client@64.174.108.131/

Sites with a reason to use dots in the username or password part must accept
(IMHO) they are broken because criminals have discovered how to steal people's
money via the Internet. To work around this, I suggest a new browsing
preference:

Preference title: When a potentially misleading address is detected
Option (default): Do not go to the address
Option: Display a warning

When triggered, and the option is set to "Display a warning", the warning could
look like Opera's dialog but with a bit more explanation:

Title: Address contains a username
Icon: Alert Message: The address contains a username and/or password. Please be
sure that the server name shown below is what you are expecting. If not, this
may be a misleading address.
Server: 64.174.108.131
Are you sure you want to continue? If you are unsure, click Cancel.
Options: OK, Cancel
Checkbox: Do not show this again for this address

Would this be acceptable as a solution?

This is more or less what the prototype patch already does.
There is no reason for there to be a warning dialog.  Displaying the . as %2e
would fix the spoofing problem without annoying users and without running into
the problem that some users ignore dialogs.
Re comment 79: The routine should also test for control chars in fake host names
due to exploits of IE parsing vulnerability. See bug 225845, comment 5.
*** Bug 228090 has been marked as a duplicate of this bug. ***
Appologies for adding "noise" to this bug, but I think its worth checking this
article:
http://www.theregister.co.uk/content/55/34447.html
In brief, a new IE exploit has been found where IE will not display any part of
a URL after an 0x01 character. In practice, a dodgy URL when clicked on an IE
user will look *exactly* like the URL it is pretending to be.

So why do we care? Because Microsoft will likely patch this bug either in this
coming "monthly update" or next months... the problem is far far too sever for
them to ignore. I don't know if they'll take the time to create a more "robust"
patch along the lines of what has been discused here, but I guess its possible.
*** Bug 228166 has been marked as a duplicate of this bug. ***
*** Bug 228176 has been marked as a duplicate of this bug. ***
Just a potential solution that I didn't see mentioned in this bug. For sites of
the form 'http://user:pass@www.server.com/path', why not simply display :

'http://www.server.com/path [login=user, password=pass]'

?

Of course, this would only be a display hack, and internal processing
(bookmarking, copying to clipboard, ...) would always use the "@" notation, but
all UI displays (status, URL bar, ...) would use the "explained" form...

Just my 2 eurocents.
I've gotten a couple of PayPal and other spoof emails which uses URL-spoofing to
try to trick people into giving up account info. It's very hard to detect
because the emails are HTML so the actual URL is hidden - all you see is a
legitimate URL (<a href="paypal.com@hacker.com">paypal.com</a>). Also, the
site's indistinguishable in its looks from the legitimate one. This is a HUGE
secuirty problem that probably all financial firms (and others) are aware of.

I also want to reemphasize what many people have pointed out, that there's
virtually no legitimate reason to use a URL with a user name that looks like a
domain name.

I want to throw out an idea that may be a little complicated and I'm not sure if
it can be implemented at this time. A dialog such as the following will force
even the most click-happy user to take notice. Starred words are bolded,
colored, or otherwise emphasized.

The link you are trying to visit appears to be an attempt to spoof a legitimate
site, using user name [paypal.com] and password []. Do you wish to:
   [ ] *Continue* on to spoof.com
   [ ] *Cancel* the visit
This 'bug' is now almost 2 years' old, having been first raised in January 2002.
 There are currently 51 people CC'd!

Most people agree something needs to be done.  The arguments centre around how
much Mozilla should act as nanny for the user, i.e. how do we implement solution?

Can I suggest a way forward:

1) All those with suggestions re-present them for a period of say 1 week.
2) Bug owner summarizes / categorizes.
3) Everybody currently cc'd on this votes on the solution.
4) Solution is implemented for v1.7.  If it causes trouble when the full
userbase tests it, different solution considered for 1.8.


Will Smith
Malaysia
You just spammed 51 people.  Thank you.  Ideas have been presented.  Please read
everything posted on the bug and comment if you have something new to add.  Just
because a bug is old doesn't mean it is ignored.
>virtually no legitimate reason to use a URL with a user name that looks like a
>domain name.

mails from hosting providers, telling users to update web pages using
ftp://their_domain_name@hosting_provider.com/ maybe?
we shouldn't dictate what kinds of usernames or passwords people are allowed to
use. Even using the single word 'microsoft' as username will probably fool a lot
of users into thinking that their at microsoft.com. A much better suggestion
IMHO is to not show the username or password in the url at all, like in comment
93 which should work just fine when displaying the url in the statusbar.

We can't do this in the url-bar though since that is an invalid url. However
couldn't we simply remove the username and password from the urlbar? If i'm
logged in to a site and then enter a url that doesn't contain the
username/password, won't we still log in using that username/password?
There have been suggestions to not show parts of the URL, e g userid/password. 
That is not good.  IMHO the two most important points in this context is:

1. The URL which is used *MUST* always be shown (complete) in the URL bar.

2. The user MUST be *very clearly informed* of the domain he is connected to
(or, if possible, he is being redirected to).

Therefore I suggest a solution like this in the URL bar (taking from an earlier
example):

(server.com) http://user:pass@www.server.com/path 

Maybe "(server.com)" should be in bold and/or red.  An alternative could be new
dedicated info field for actual domain.  But the latter would take unnecessary
space, I think.

A  feature of lesser importance would be an option to block URL's that contain
an user/passw prefix which is in a format resembling a domain and/or is beyond a
certain length (the latter to e g block URL's with the prefix part of such a
length that the domain is not visible in the URL bar).
I suggest this feature work like the popup blocking.
Initially all http (not ftp) requests with username/password are blocked and an
icon appears in the statusbar.  You can then unblock the specific site or turn
the block off.
Are there any useful, legitimate uses of username/passwords in http requests?

The work can be divided:
1) fix status bar
The status bar not showing the correct location is clearly a bug #228176.
2) (optional) Color highlighting for URL in statusbar/addressbar
3) (optional) Implement blocking
I wonder if instead of creating yet another annoying dialog, we could make the
problem more generic and obvious, and maybe easier-to-use (ease-of-use I'll
leave to the experts).	How about if a URL contains a username/password,
Mozilla strips those out of the URL field (as hinted at above) and puts them
below the URL bar.  Then it becomes obvious that something funny is happening. 
I don't think it's a good idea to try to anticipate 'badness' of user/pass
encoded URLs, and I'm not sure if this is something that would have to be
'always on' for consistency, but I thought I'd throw it out as an idea.  A
general-feel-for-it mockup is attached.  The top represents the way it is
today.	The bottom is the way it could be.
I like the concept in <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=122445#c101">#101</a> as long
as make sure that those OTHER boxes would ONLY show if it's a url with a user
and password in the URL.  Otherwise all the newbies would be confused as hell.

Also, how would this affect HTTP username and password realm authentication?
Attached image Mockup of alert idea — 
This mockup presents a concept similar to popup blocking.

If you want to continue, click the little icon in the bottom right of the
browser. At that point, you decide whether to enable access once, allow this
site forever or allow all sites.

If you are a fool who doesn't read dialogs, you will be protected against your
own stupidity.
First off.

>>virtually no legitimate reason to use a URL with a user name that looks like a
>>domain name.

>mails from hosting providers, telling users to update web pages using
>ftp://their_domain_name@hosting_provider.com/ maybe?

I forgot about ftp, but I was just talking about http. If someone's using ftp
they can hardly be spoofed unless they're brainless. And I don't mean figuratively.

Now, on #101: what if someone has a tiny toolbar, eg with small icons? What if
they don't even have a location bar? (Have to consider all cases) Would it work
with all chromes/themes?

On #103: I think this can be a good idea if people don't think it'd clutter the
status bar or something. :) But I think the message has to be very clear on why
this may be fraudulent. To the average user this dialog tells them nothing about
the reason, which is very important.
i think that this bug have several parts, each should be fixed:

1-the long username problem: any username bigger than say 16 characters should
be marked as "BAD thing". A long enough username cam make this bug into a
security problem like bug #228176, so reporter or someone with enough power
please update the status, add the security flag there
i know no real system that uses usernames bigger than 16 characters, and if they
exist, they should be rare

2-the same for the passsword (or maybe some more characters, about 20?)

3-both username and password bigger than 20 character also marked also as "BAD
thing" (most people enter the password after, in the login dialog, this
combinations is less usuall)

4-any username with a "." in it should be marked as bad

5-the username/password looks too much like the real URL, it should be ALLWAYS
some_color/gray (username red/blue/green, password grey, so the password is
harder to read by any guy near us)
maybe the username or the real URL in italic/bold is a good thing also

6-the status bar, should display the real URL and then the (username:password),
as its more important to see here we are going than if the login is the correct
or not
the username:password should be allways show in the end, but as the rule above,
only the max of 32 characters will be shown, as the other will be marked "BAD
thing" and the popup dialog will take care of then

7-all marked "BAD thing" url should get a popup dialog, stating that the user is
trying to acess "the real URL" with username "username" and password "password".
the dialog then ask to allow or not (and so should have the buttons "allow" and
"abort")
if allow, it should store that information for the session, as this kind of
login are also just stored for the session
also, maybe a note in the dialog stating that the username will be show as
red/green/italic/whatever in the url bar might be a good idea


we cant hide the username:password because some sites require login to use
special things and the url might be the only place they have the username and
password, and viewing the html source isnt one option for this kind of people

at least issue 5 should be fixed ASAP to reduce the danger of this security
problem. if this existed,bug #228176 would be less important, as the url would
show in a different color, pointing to something fishy...


>i know no real system that uses usernames bigger than 16 characters, and if they
exist, they should be rare

I am not so sure how rare they are. I have seen system where the username
matches the person's full name. In that case, it can easly exceed 16 characters
(take may full name for example: ShoshannahForbes- it is exactly 16 characters).
re comment #102 My idea is that mozilla would simply parse the URL and put the
appropriate data in the fields, or extract the data from those fields to
construct the URL behind the scenes.  I think it's easier for the realm
authentication, personally, because you can type the URL as given (if given) OR
type the URL with the username and password in the username and password fields.
 If authentication credentials are present you are logged in directly (cuz
that's just how it works).  However, this lends itself to demanding that both
fields (or at least just the login, Mozilla could prompt for a password like it
does for email, etc) be always present.  I'm thinking that this isn't a bad
thing.  A future enhancement could be that Mozilla puts the user-provided realm
login data into <form> logins, if present, just to add some slickness.

The advantages to this are twofold:  It is OBVIOUS, and it is NONINTRUSIVE.  I
like the idea of coloring, but colors are confusing for newbies.  This seems
very blatant for newbies.  The people who would have the most trouble are the
experts, because it's different.

For chrome issues, I don't see an immediate solution to the "small-icon" problem
(comment #104).  For the "no location bar" issue, I say this is invalid.  If you
don't have a location bar, you have no indication of what site you are on
anyway.  Of course, this depends on what problem you're trying to solve.  This
may just be a new bug.
This is a simple HTML doc with example links. One simple spoof, one new spoof
based on the newly discovered IE flaw and one "legitimate" link containing user
name and password. I'd like to draw attention to the fact that example link 2
shows *only* the spoofed URL in the status bar of Mozilla!

(I'm sure many people are aware of this, but I wasn't so this post is for the
benefit of anyone else who didn't realise that this IE bug also partly affects
Mozilla).
I read this whole bug over the last two days. Many peoples ideas initially seem
like a good solution. However, we must examine this issue with a lot of
thought.

A dialog box is not a good solution and this is why:
1) Most users don't read them
2) You will anger website owners who give out legitamite links and their users
get shocking security warnings when nothing is wrong.
3) Mozilla cannot be the judge of legitamite urls, that is for the W3C.
4) Bugzilla is not a fair place to decide how widespread HTTP Authentication is
used, Apache today is used on 60% of web servers and HTTP Authentication is
wildly popular and with that popularity is the use of links with the username
and password embedded.
5) If you allow the ability to uncheck that the warning from showing up again,
then novices will uncheck that and have no protection when they are spoofed in
the future. If you don't allow the dialog box to be disabled in the future,
then you basically are breaking the way the web works.
6) This is a slippery slop to having a dialog when a website from another
domain is loaded in a frame. A lot of spoofing happens at hotmail where you
cant even see the url, so the username and password spoof trick isnt even used.


Changing how the URL is displayed in the address bar will not work because:
1) There is a long history of giving the exact url in the address bar, and
Mozilla will not gain popularity if you chop up and colorize the url. People
need to be able to see and manipulate the full url.


Mozilla needs to be forward thinking. The best solution is the one that
requires the least amount of education, because educating the whole world is
impossible. Also, the best solution allows security conscious websites (ie.
banks, paypal) to educate their users on what to trust.
For example PayPal tells their users, only enter your PayPal information when
you see:
https://www.paypal.com
Now we know that can be spoofed:
https://www.paypal.com:cmd%20adfa2lkjr39i7a23971n1l3ku497ibuka23lkjs7@gotallyourmoney.com


I have attached a crude mock up of a GUI that could be implemented to solve
this problem properly for all time.

The users will look at the location bar when determining if a site is
trustworthy or not. For that trust we need to give the URL, the hostname and
the lock icon so they know they can enter credit card information. When a
website is locked we can also show the organization. There would also be room
(it's not shown in the attachment) to place the trust authority (eg.
verifysign, geotrust).

Educating users on how to use the information shown in my attachment is far
easier than teaching them how to parse the URL and I believe it's such an
obvious way to show the information that no education would be required.
How is that different from the other proposed item:
http://bugzilla.mozilla.org/attachment.cgi?id=137342&action=view

The same problem of screen real-estate exists.
It also does nothing for non-SSL sites.
alanjstr,
actually it's similar on the surfer to that attachment but differs in two
important areas:
1) The attachment I uploaded does not remove the username and password from the url.
2) Since the vast majority of sites are visited without a username and password,
it's far more useful and astetically pleasing to have a hostname box which is
filled on every site and it provides a consistant location for users to look to
see if they trust a certain site.

attachment 137342 [details] is a good idea, but I believe that attachment 137416 [details] is an
improvement on that idea.

Yes the same problem of screen real estate exists, but if we cannot allocate a
little amount of real estate to this issue, then it's probably not an important
enough issue to fix.

Aaron,
>It also does nothing for non-SSL sites
It clearly shows the hostname for SSL and non-SSL sites. The hostname cannot be
spoofed and users will know they are not at www.microsoft.com if the hostname
box has www.evilspoofersite.com
Re comment 109: Something like that for SSL was already suggested in bug 184881,
and I had an additional hostname field in mind since a long time already, see
bug 228524.
However, the suggestion in comment 109 won't fix this bug, see bug 184881
comment 8. You'd have to remove the URLbar (bug 228524), but I don't expect that
to happen for Seamonkey.

So, IMHO, Jesse's suggestion of escaping "." in username would be least
obtrusive and most effective for now.
Code-wise, how about consistently (for status bar, URLbar, etc.) using a
function like UnEscapeURIForUI and there implementing that special escaping?
Another solution that doesn't break FTP links can be found in bug 228612.
Would it not be better all round to remove/censor the username & password anyway? 
[these things are fairly stupid in practice since your username and password are
displayed in clear text]

Maybe for display purposes, replace the username and password with 'user' and
'pass' in square brackets?

http://fred@whereever.com -> http://[user]@whereever.com
http://fred:bert@whereever.com -> http://[user:pass]@whereever.com

[and maybe if you click in the URL, it shows the actual username and password?]
Blocks: 212999
*** Bug 229301 has been marked as a duplicate of this bug. ***
My votes are to display near/in the URL bar a hostname when the user/password
seem questionable.

ie:  
[hacker-site.ru]http://www.bigbank.com%04login.php?secure=1&@hacker-site.ru/accountaccess.php

and for some indication by the lock icon of what hostname the SSL cert is for. 
(Even if that just means a tooltip when you hover your mouse over it saying
[accounts.bigbank.com]
While I think the change to the URL by prefacing the hostname [hacker-site.ru]
would be the most blatant and easy to recognize by ininformed users, other
suggestions to change color of user/password are probably a close second.  While
a user may not know why that part of the URL is bold and bright red, it should
at least give them cause to stop and think before blindly entering account or
personal info.

So... color-coding the user/password portion of the URL also gets my vote. One
advantage it would have is you could still copy/paste the URL from the address
bar without getting any extra 'stuff' along with the address.  And I'm
absolutely against a pop-up dialog of some type.
I think color is better than displaying the [host.name] next to the URL, simply
because changing the color of authentication tokens in the URL can always be
done, whether we think the URL is suspicious or not.

The suggestions to display the hostname based on the result of some heuristics
run against the URL are fine in theory, until someone works out how to run a
fraudulent web site which doesn't trip any of the heuristics.  

Making usernames in URLs bright red whether they're fraudulent or not is an
end-run around that problem which doesn't involve any pesky alerts.
URL coloring and dialog boxes are not mutually exclusive. Please file a new bug
for that discussion.

As for the dialog warning logic, I think that any "." should trigger the
warning. Please give an example of how you could spoof around this.
I did file a new bug.  It got tagged as a duplicate of this one and closed :-)

How about changing the mouse cursor on mouseover of such a link? The mouse
cursor could be changed to a "skull and bones" icon, for instance.

For keyboard navigation, the focused link could be outlined as normal, and a red
slash could be placed over the anchored element.
Flags: blocking1.7a?
Well, apparently we have a number of ideas (toolbar, dialog, cursor, etc.) for
how to deal with spoof URLs. Every day that goes by, someone is tricked by a
fake Paypal/Ebay/AOL email. We need to decide what technique to adopt - NOW!

Perhaps we can set up a poll to quickly figure out what the majority wants and
go from there. I would really like to see this feature appear in 1.7, and if we
get moving we can do it.
Flags: blocking1.4.2?
There's no way this is  1.4.2 or 1.7a blocker; that's generally for bugs
introduced by recent patches.  Someone from Paypal/Ebay should offer a small
bounty to the person providing the patch that fixes this bug. 
Matthew: in much the same way as you spammed dozens of people, i'm doing the
same now. Please let the drivers decide on what's a blocker or not.

Furthermore, imho your statement is incorrect. Giving users a reliable and safe
browsing experience ARE of core importance for a browser. Also your "recent
patches" statement does of course not apply to a browser that has already been
released. And finally, i don't think it's Mozilla's goal to wait for/require
donations from parties that are victims of malacious sites before a bug is fixed.

I'm sending this out in the hope that all future comments are aimed at getting
this bug fixed.

[and my apologies for the spam]
There is a prototype patch for this bug already attached. I received precisely
zero comments about it and yet I see people raising points that it addresses
over and over.

To recap (see comment 79 for full blurb) - it counts the number of dots and a
few other things in the userpass part of the URL. If it considers the URL
'dubious' it throws the error warning. 

As I mentioned before it has limitations (it should be a confirmCheck for one
thing), but I would be glad if someone would say something about it one way or
another!
Thanks for your patch, Adam. First of all, I apologise for posting comments after your comment #79 without reading your code! The patch is great. It certainly addresses the issue raised by this bug as it stands. My comments are:I was confused initially by the "if (dubiousness > 1)" test. At first I thought it meant no dots are allowed but then I realised it means one dot is allowed. For readability please could you change that to "if (dubiousness >= 2)"?I think it would be a good idea to also check for dot-like characters such as comma and dash. Something like:+if (*iter == '.' || *iter == ',' || *iter ==';' || *iter == '-' || *iter == '_')+   numDots++;This is because scammers might try to work around Mozilla's detection by using non-dot separator characters. I would think there is something strange about "ebanking-abbeynational-co-uk" but naive users might not notice.The patch checks for the presence of "www" which I think is good. There are no words I know of that contain "www" so that seems a pretty sure sign of a fake URL. I know of some potential victim sites that do not mention www in their URL but they do at least have two or more dots.I'm not sure about testing for "com". There are lots of English words that have the letters "com" in them. A quick search of /usr/share/dict/words for "com" reveals 543 words. Examples: becoming, forthcoming, outcome. All of these words would make at least usable legitimate passwords, or parts of good passwords. As for mentioning specific examples of commonly scammed sites, "ebay", "paypal" and "amazon", I worry that would be difficult to maintain because the list of potential scammed sites is very long and constantly changing. Also, the word "amazon" would make a legitimate password, or part of a good password.The "spoofURL" warning message is excellent because it mentions the context that the warning might appear in, ie after clicking a link in an untrusted source such as unsolicited email. It says what is wrong with the link (resembles one web address but direct you to another) but I think it could be clearer. For example, it could say "Mozilla thinks the link you have clicked on may be a fraud". The word "formatted" is jargon that may not be very meaningful to some users, especially inexperienced users. It might be a good idea to state the real address (eg bad.site.ru) and say something like "if this is not what you are expecting then you should check with your provider before you proceed."If the message were in a confirmCheck dialog then perhaps it should say something like "If you are sure you wish to proceed, click Continue. Otherwise click Cancel (recommended)." This would borrow from the style of some MS dialogs where they give options and it says which one they advise the user to choose.Here is suggested modified spoofURL code:+spoofURL=Mozilla thinks the link you have clicked on may be a fraud. It is actually a link to the web address '%S'. If this is not the web address you were expecting, you should check with your service provider before you proceed. If you received this link from an untrusted source such as unsolicited email you should exercise extreme caution before entering personal details such as login or passwords. If you are sure you want to continue, click Proceed. Otherwise click Cancel (recommended).There is a related issue here to do with users that don't read dialogs. Unfortunately we are not the only browser. If Mozilla refused to load the address, as I advocated earlier, an uncomprehending / stupid user would assume Mozilla is broken, which it isn't, and then switch to a dumber browser, which would be a disaster! So I think the best we can do is offer a dialog for users who do read dialogs, and then we can say we tried. :-)
Oh no. I'm sorry, my posting doesn't seem to be newlined properly. Apologies 
everyone, here it is again. I hope it works properly this time.

Thanks for your patch, Adam. First of all, I apologise for posting comments 
after your comment #79 without reading your code! The patch is great. It 
certainly addresses the issue raised by this bug as it stands. My comments are:

I was confused initially by the "if (dubiousness > 1)" test. At first I thought 
it meant no dots are allowed but then I realised it means one dot is allowed. 
For readability please could you change that to "if (dubiousness >= 2)"?

I think it would be a good idea to also check for dot-like characters such as 
comma and dash. Something like:

+if (*iter == '.' || *iter == ',' || *iter ==';' || *iter == '-' || *iter == '_')
+   numDots++;

This is because scammers might try to work around Mozilla's detection by using 
non-dot separator characters. I would think there is something strange about 
"ebanking-abbeynational-co-uk" but naive users might not notice.

The patch checks for the presence of "www" which I think is good. There are no 
words I know of that contain "www" so that seems a pretty sure sign of a fake 
URL. I know of some potential victim sites that do not mention www in their URL 
but they do at least have two or more dots.

I'm not sure about testing for "com". There are lots of English words that have 
the letters "com" in them. A quick search of /usr/share/dict/words for "com" 
reveals 543 words. Examples: becoming, forthcoming, outcome. All of these words 
would make at least usable legitimate passwords, or parts of good passwords. 

As for mentioning specific examples of commonly scammed sites, "ebay", "paypal" 
and "amazon", I worry that would be difficult to maintain because the list of 
potential scammed sites is very long and constantly changing. Also, the word 
"amazon" would make a legitimate password, or part of a good password.

The "spoofURL" warning message is excellent because it mentions the context that 
the warning might appear in, ie after clicking a link in an untrusted source such 
as unsolicited email. It says what is wrong with the link (resembles one web 
address but direct you to another) but I think it could be clearer. 

For example, it could say "Mozilla thinks the link you have clicked on may be a 
fraud". The word "formatted" is jargon that may not be very meaningful to some 
users, especially inexperienced users. It might be a good idea to state the real 
address (eg bad.site.ru) and say something like "if this is not what you are 
expecting then you should check with your provider before you proceed."

If the message were in a confirmCheck dialog then perhaps it should say 
something like "If you are sure you wish to proceed, click Continue. Otherwise 
click Cancel (recommended)." This would borrow from the style of some MS 
dialogs where they give options and it says which one they advise the user to 
choose.

Here is suggested modified spoofURL code:

+spoofURL=Mozilla thinks the link you have clicked on may be a fraud. It is 
actually a link to the web address '%S'. If this is not the web address you were 
expecting, you should check with your service provider before you proceed. If 
you received this link from an untrusted source such as unsolicited email you 
should exercise extreme caution before entering personal details such as login 
or passwords. If you are sure you want to continue, click Proceed. Otherwise 
click Cancel (recommended).

There is a related issue here to do with users that don't read dialogs. 
Unfortunately we are not the only browser. If Mozilla refused to load the 
address, as I advocated earlier, an uncomprehending / stupid user would assume 
Mozilla is broken, which it isn't, and then switch to a dumber browser, which 
would be a disaster! So I think the best we can do is offer a dialog for users 
who do read dialogs, and then we can say we tried. :-)

>Here is suggested modified spoofURL code:

that text is _way_ too long. very few users will actually read it (even fewer
than would normally).
The reason we have standards on the web is to promote freedoms.
Warning a user when they visit any url is against the goal of standards and
freedoms. Mozilla is then imposing it's version of what is right and what is
wrong. This is not the job of Mozilla. This is the job of the standards body.
One of Mozilla's shinning attributes is that it follows the standards very
carefully. 
Any attempt to analyze urls for "fraudulent" urls is self defeating and can put
mozilla in a position to be sued for libel. Because if I ran a huge site and a
new version of Mozilla came out that was warning my users that the site might be
fraudulent then I would be in a position to sue The Mozilla Foundation for libel.

I strongly urge against this course of action.

For a more reasonable solution please view Comment #109 and other suggestions
that propose long term solutions to this problem by having better GUI interfaces
for recognizing what site you are at.
> The reason we have standards on the web is to promote freedoms.

No they're not. They're to ensure interoperability, they have nothing to do with
freedoms. (Free software has a lot to do with freedoms, but free software and
standards are completely unrelated.)


> Any attempt to analyze urls for "fraudulent" urls is self defeating and can 
> put mozilla in a position to be sued for libel.

Opera does this, and hasn't been sued for libel. I seriously doubt Mozilla would
be. It already says "Warning you could be being watched" for a number of things,
such as searching on google, as have almost all browsers for almost a decade,
and nobody has been sued for libel. Let's please stay realistic here.
Re: Peter Kroll's recent message.

Furthermore, the standard is flawed. 

Allowing these kinds of URLs was fine a few years ago. Today, however, it
creates a security hole ever more commonly exploited. The Mozilla Project does
need to honor standards. Yet, when the purpose of a certain standard is no
longer relevant, or is outweighed by other concerns--such as security--then we
have to react to the changing real world conditions. I'm in favor of fixing this
bug.
Interoperability has everything to do with freedoms, specifically the
freedom to choose a provider of computer programs.

And Andrew Hagen is right: just because something is a standard doesn't mean
it's safe.  TFTP is a standard, but it has security holes.  SSH version 1 is
a standard, but it has security holes.
I am still strongly against a pop-up or dialog box as the only alerting method.
If a user regularly visits a site which includes username/password information,
they will soon grow tired of the alerts and simply turn them off.  If we don't
allow the option to turn them off, then it will just seriously annoy/irritate
them.

Once a user turns off the alert, they'll no longer have any indication that
something might be wrong when they visit a spoofed address.  Therefore users who
regularly visit URLs that yield false positives, will reap virtually no benefit
from the patch.

Colorizing the user:password portion of the URL won't affect real estate, and
won't prevent copy/paste of the URL.  It will, however, be a constant but
inobtrusive visual indication that the URL is not "normal."  It also isn't
subject to a scammer engineering their URL to bypass Mozilla-specific
"dubiousness" tests.

I personally feal the dialog box is a futile effort, however, if it is going
to be used, please leave a way to easily disable it and please still consider
displaying the user:password portion of the URL in a different color.
RE: Cory Jaeger's Message

> Colorizing the user:password portion of the URL won't affect real estate, and
> won't prevent copy/paste of the URL.  It will, however, be a constant but
> INOBTRUSIVE visual indication that the URL is not "normal."
(emphasis added)

The same reason you like your idea is exactly why it would be utterly useless.
If it is not obvious and/or obnoxious it will be easily ignored. Dialogs may be
annoying, but they grab your attention like nothing else will.

If you wish to disable the dialog, there should be a checkbox within the
preferences (not on the dialog itself, too easy) - buried deep enough that only
those that know what they're doing would find it.

This may seem like nasty medicine to some. However, we must remember that
Mozilla is now gearing itself towards the general public. The general public
often does not know what they are doing. Therefore, we must deal with a little
annoyance for the good of the masses/newbies.
Attached patch Patch — — Splinter Review 
Here is a patch based on the earlier prototype. I've taken into account some of
the comments about it and it now checks for dot-like chars as well. I have also
tightened the string checking by looking for a dot-like char before the com and
before or after the common scam names to reduce false positives. I know paypal,
ebay etc. are not the only victims of scams, but they must represent a good 80%
of them.

The dialog wording has changed although I do not say "fraud" anywhere because
the simple fact is we don't know if the site is the fraud. We can guess but we
don't know. I also don't display the URL - scam URLs can be massive with
embedded non-printable chars (or escaping) so it would be pointless to shoehorn
it into a common confirm dialog when it will make it the width of the screen.

It would be nice to have a dedicated warning dialog (like the popup killer)
with the URL broken down into pieces, nice scary graphics etc. But I consider
this a good first step, ready for review.

Please move general debate about the whys and whatnots of scam detection out of
this bug please.
Attachment #136315 - Attachment is obsolete: true
> If it is not obvious and/or obnoxious it will be easily ignored. Dialogs may be
> annoying, but they grab your attention like nothing else will.

If you prevent sites from spoofing, then there's no need to "grab the user's
attention", and even users who ignore dialogs will be protected.
adam: Two comments: First, the spoof checking seems incredibly overcomplicated.
Can't we just search for dot-like characters and the moment we find one, assume
it's a problem case? Second, the warning is to long. I don't have a suggestion
on shortening it, really, but more than two sentences is just too long, and
nobody will read it, even if it says "please read this carefully".

(I've seen users who, upon seeing the alert "This file name already exists.
Please chose another." or similar, turn to me and say "help!" without even
reading the message.)
how about changing the dialog to Yes/No and the message to the following?

Mozilla thinks the link you have clicked on may be a fraud: it is actually a
link to the web address "%S". Are sure you want to continue?
I *still* think that the best (and least obstrusive in many ways) is to 
*display* the domain in the actual URL in the URL bar this way:

(server.com) http://user:pass@xxx.yyy.zzz.www.server.com/path...

*Please* remember that the actual the problem is that the user don't *see*
"http://www.server.com" etc.  It's *equal* bad from the user's point of view if
he goes to "http://www.bigfraud.com" as to
"http://user:pass@xxx.yyy.zzz.www.bigfraud.com/path...", but we still don't try
to solve/help the user with the "http://www.bigfraud.com" case !!

So, to reiterate, we want to be sure that the user is as clear where he is as if
there were "http://www.server.com" in the URL bar.  And I think we are with this
solution.
I suggest changing the dialog verbage in the patch to the following:

"The link you have clicked on has been formatted to look like one URL but direct
you to another. You should exercise extreme caution before entering any personal
information such as passwords or credit card information.\n\nTo protect your
security, Mozilla suggests that you click Cancel."

Other thoughts:
- Cancel button must have focus by default.
- Remove the do-not-show checkbox, it makes it too easy for fools to dismiss the
dialogs. The option should be in the preferences, as I have stated before.
- If the user clicks Cancel, display a "Page load cancelled by user" message
within the browser. This lets the person know that they chose to stop the page
load, that it is not a problem with Mozilla.
>Mozilla thinks the link you have clicked on may be a fraud: it is actually a
>link to the web address "%S". Are sure you want to continue?

Yay! Well done, Louis Bennett. That is brilliant. I'd certainly like to see that 
message in Mozilla.

Comment #140
(server.com) http://user:pass@xxx.yyy.zzz.www.server.com/path...

this is the most sensible/benefitial/simple solution available.
it's not annoying and it's obvious to users. when you add the pro vs the cons
this may be the best solution for a 1.7 or 1.8 time frame. because it's not a
major GUI change.

(server.com) can be shown for all urls in the location bar, but have it not
selectable. so that people still get the same functionality of copying and
pasting the url from the location bar as they do now.

example: the names would not be shown it's just so i can textually show you what
I mean. the favicon is not currently selectable and would remain unselectable.
the host would be new and would be unselectable. the url is as usual and is
selectable.

fav      host      selectable url
 M   (server.com)  http://www.server.com/dir/page.html
> (server.com) http://user:pass@xxx.yyy.zzz.www.server.com/path...
> this is the most sensible/benefitial/simple solution available

No. See comment 68, 2d).
Ben. I agree #68 2d) is the simplist fix. And it's far better than a dialog box.

My personal opinion is the proper fix will eventually show the host name.

I dont want to get off topic, but some solutions in this bug are attempting to
have mozilla police the internet. I think the best solution solves this problem
without policing.
If Mozilla gets involved in policing we should filter unencrypted post data
whenever a 16 character field is sent that starts with 4 or 5 cause it's likely
a Visa or Mastercard number.


Adam Lock wrote in comment #136:
> I do not say "fraud" anywhere because the simple fact is we don't 
> know if the site is the fraud. We can guess but we don't know. 

True. But Louis Bennett's suggested wording in comment #139 is "Mozilla thinks 
it *may be*". Not "*it is*".

In my (unscientific) 'wife test', Louis' dialog wording seemed to get the 
message across immediately. All other dialog wording suggestions, including 
mine, did not do so well.

> I also don't display the URL 

Yes. I think that's a really good idea.

I must be really dumb, but it seems to me that rfc2616 doesn't allow
usernames/passwords in http uri:

3.2.2 http URL

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

so they could be just stripped away (at least for http,https)

No-- RFC 2616 defers to RFC 2396 on URL syntax in section 3.2.1: "For definitive
information on URL syntax and semantics, see [...] RFC 2396". And RFC 2396 does
allow for "<userinfo>@..." in the URL.
Since this is closely realted to this problem, Ive copied/blatantly-ripped
portions of RFC 2396 for your inspection. For those who would care less, I am
sorry for the bugspam.

Full spec available at: http://rfc.sunsite.dk/rfc/rfc2396.html

RFC 2396                   URI Generic Syntax                August 1998
Berners-Lee, et. al.        Standards Track     [Portions of Pgs. 13-14]


3.2.2. Server-based Naming Authority

   URL schemes that involve the direct use of an IP-based protocol to a
   specified server on the Internet use a common syntax for the server
   component of the URI's scheme-specific data:

      <userinfo>@<host>:<port>

   where <userinfo> may consist of a user name and, optionally, scheme-
   specific information about how to gain authorization to access the
   server.  The parts "<userinfo>@" and ":<port>" may be omitted.

      server        = [ [ userinfo "@" ] hostport ]

   The user information, if present, is followed by a commercial at-sign
   "@".

      userinfo      = *( unreserved | escaped |
                         ";" | ":" | "&" | "=" | "+" | "$" | "," )

   Some URL schemes use the format "user:password" in the userinfo
   field. This practice is NOT RECOMMENDED, because the passing of
   authentication information in clear text (such as URI) has proven to
   be a security risk in almost every case where it has been used.

   The host is a domain name of a network host, or its IPv4 address as a
   set of four decimal digit groups separated by ".".  Literal IPv6
   addresses are not supported.

      hostport      = host [ ":" port ]
      host          = hostname | IPv4address
      hostname      = *( domainlabel "." ) toplabel [ "." ]
      domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
      toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
      IPv4address   = 1*digit "." 1*digit "." 1*digit "." 1*digit
      port          = *digit

   Hostnames take the form described in Section 3 of [RFC1034] and
   Section 2.1 of [RFC1123]: a sequence of domain labels separated by
   ".", each domain label starting and ending with an alphanumeric
   character and possibly also containing "-" characters.  The rightmost
   domain label of a fully qualified domain name will never start with a
   digit, thus syntactically distinguishing domain names from IPv4
   addresses, and may be followed by a single "." if it is necessary to
   distinguish between the complete domain name and any local domain.
   To actually be "Uniform" as a resource locator, a URL hostname should
   be a fully qualified domain name.  In practice, however, the host
   component may be a local domain literal.

      Note: A suitable representation for including a literal IPv6
      address as the host part of a URL is desired, but has not yet been
      determined or implemented in practice.

   The port is the network port number for the server.  Most schemes
   designate protocols that have a default port number.  Another port
   number may optionally be supplied, in decimal, separated from the
   host by a colon.  If the port is omitted, the default port number is
   assumed.
Yes, I looked at rfc2396 before sending my comment, specifically the introduction:

"This document defines a grammar that is a superset of all valid URI,
such that an implementation can parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier type.  >>>>This document does not define a generative
grammar for URI; that task will be performed by the individual
specifications of each URI scheme.<<<<"




And if you look at rfc2616 where it references rfc2396 it says in section 3.2.1: 

This specification adopts the
definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
"host","abs_path", "rel_path", and "authority" from that
specification.

and the specification of "host" in rfc2616 (section 3.2.2) doesn't include a
"userinfo", that's the definition of "server".

RFC 2616 describes the HTTP-protocol, NOT HTTP-uris. RFC 2616 delegates that to
RFC 2396 or to RFC1738 which has a specific section about http-uris. 

In my opinion RFC 2616 just defines a "simple" version of http uris as it was
needed to explain the http protocol. RFC 2396 is the definitiv resource for URIs
and RFC 1738 makes clear that username:password is possible (Section 3.1):

   ...
   While the syntax for the rest of the URL may vary depending on the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:

        //<user>:<password>@<host>:<port>/<url-path>

   Some or all of the parts "<user>:<password>@", ":<password>",
   ":<port>", and "/<url-path>" may be excluded.
   ...

And section 3.3:

   ...
   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1.
   ...
Peter, re: freedoms and standards, read "Code and Other Laws of Cyberspace". 

In cyberspace,  code is analogous to law (because it defines the behavior of the
program), and standards are analogous to comon law and/or social norms. 

If we do stupid things, like create browsers where every link could say one
thing and do another, then we've created a fraud-ridden world. 

The internet as achitected, does inherently promote some types of freedom, but
that does not exclude it from having elements of thoughtless design.
--
That being said, I'd like to propose the following:

1- Get a dialog box checked in that flags only the worst kind of spoofing.
2- See what the reaction is into 1.7a.

THEN debate this further, perhaps in a followup bug.

I know this bug is long, but the posts increasingly reflect a lack of having
read the previous posts.

"HTTP doesn't have username in URLS" - it does. Seach Networking:HTTP for "@" 
"I don't think this is a serious security threat" - you can find stories of
citibank spoofing in news.com
"How can we colorize the URL?" - please move that to another bug!

In a perfect world, I would have written more URL documentation to discuss the
basis of this, but instead, I need to simply insist that we stop having certain
threads that are not relevant.

One last relevant comment. If a user gets a dialog, and then says "don't show me
again", then that means either:

1- We warned them this was a problem, and they understand how to spot this and
not get spoofed.
2- They decided they just didn't want to be bothered, and they want to go
through life at an level of unsafety that the other browsers offer. 

One relevant comment:

But by having the dialog, I think we have fulfilled our obligations of caring
for their security. I think the other standard dialogs that we pop-up for
security, actually are bad dialogs, and potentially should be removed, because
they come up too often, and "cry wolf". 

I think we have established that very few legitimate sites use urls that would
trip this dialog. 
benc, Ill look into reading that book, next time I make a book purchase.

Just a note, I have read all the comments in this thread. It's hard to remember
them all because there are so many.

I think dialogs are disruptive. They are good in some circumstances, but usually
not a good way to give education. Good for things like hostname not found.

Why not use the status bar to give a message?

Spoofers have to host their website somewhere, what's to stop them from
registering update-paypal-info.com
How is this dialog going to HELP stop people from being victimized. Answer is a
dialog won't. This is just a way to clear peoples conscience as many have mentioned:
"At least we've done our part"

This bug addresses larger issues than warning for username/password in url.
Question:
How will Mozilla 2.X be different from 1.X?

Maybe we should think up a smart and intuitive interface where people can't be
confused as to where they are.

Otherwise, as the months pass we will just be adding more and more dialogs till
people are just as annoyed with dialogs as with popups.

This bug and it's discussion has raised a lot of issues. The dialog that comes
up the first time a user sends unencrypted data is just as stupid as a dialog
for this issue. We have a lock icon, we don't need a dialog. And if we had an
extra spot for hostname we wouldnt need a dialog for this issue.

Maybe we should put those GUI items near each other and have a trust rating. 1
to 5, kind of like the terrorist threat level. And when people visit a site a
trust level is determined. This way banks can follow all the rules make sure
they have a 5 for trust level and users will only enter their banking/credit
card information there. Have Visa and Mastercard digitally sign domain names
that should be accepting credit cards and let that information be shown through
mozilla. This kind of thinking will make mozilla a secure browser to use for
online commerce and make it a recommended choice by banks and such.

Hopefully you can see I'm really trying hard to come up with an idea that will
actually solve this problem, not just annoy people with more popup dialogs.
"Why not use the status bar to give a message?"

First, most users are not technical. They do not look at the status bar. When
they do, they do not know what it is. 

Second, there is no status bar in full screen mode (kiosk mode) (F11).

Like the man said, let's put a dialog box in 1.7a and see how many bellyaches we
get.
Blocks: majorbugs
Interesting: M$ plans to update the IE


Microsoft plans to release a software update that modifies the default behavior
of Internet Explorer for handling user information in HTTP and HTTPS URLs

http://support.microsoft.com/default.aspx?scid=kb;[LN];834489
User-level workaround :
I followed this bug for quite a long time and finally settled on a non-intrusive
way to warn users even before they click on such links, by styling those links
to make them stand out of the page. The result - see screenshot - is of course
perfectible, but already sufficient to alert users.

To do this, I just added the following 2 lines to my userContent.css :
a[href*=".com@"]:before { content:
url(http://lxr.mozilla.org/seamonkey/source/themes/classic/global/win/icons/alert-exclam.gif?raw=1)
}
a[href*=".com@"]:after { content: " [ Warning : this link could be an attempt to
mislead you. Please exercise extreme caution if you decide to click on it ]" }

(and so on for .com&, .net@, .net&, .org@, .org&)

Note : a tooltip on the warning sign would be nicer, but I don't think it's
possible using CSS alone. However, Mozilla could of course implement that more
elegantly

(Credit : inspired by http://www.squarefree.com/userstyles/userContent.css.txt)
Given that Microsoft plans to update to IE to complete do away with ALL
HTTP/HTTPS AUTH, rather than attempting to sanity check them in any way, all I
have to say is TFB to all your whiners who complained about how my original idea
in the bug report to only care about .'s in usernames because it might
inconvenience a dozen users at some obscure site or another using HTTP AUTH
that's dumb enough to have usernames with dots in them.

Mozilla should now just follow suit and disable ALL uses of HTTP AUTH in the
browser because standard or not, now that MS is obsoleting it, the few remaining
sites legitimately using will cease soon enough when they have the first reports
from IE users with the patch that it no longer works and they realize MS will no
longer support it.

Of course I expect in reality that Mozilla will continue to do nothing, as those
same whiners that obstructed anything constructive being done, like Adam's patch
that apparently was never considered by anyone with any power in the Mozilla
organization to do anything about it, to continue to whine about how Mozilla
should continue to support HTTP AUTH anyway, because it is the "standard", even
though only sites used where no users use IE would continue to use the
brain-damaged HTTP AUTH option from this point on.

Thus insuring that not only did Mozilla not take the leadership on this issue,
despite my bug report being filed TWO YEARS AGO TOMORROW, it will probably
remain for quite a while as the only browser still vulnerable in all its
versions to the phishing scams.  I'm sure those will go on for quite a while
since there will be enough vulnerable versions of IE out there for several more
years.

No wonder Mozilla never went anywhere, people were too worried about stupid ****
like themes and support for stuff no one uses like SVG and MNG, instead of
worrying about things that will benefit the average end user.  Mozilla should
just give up any illusions it is for the average user, and just content itself
to be a geek browser for people who are already too smart to fall for such
scams, and those of us who got their friends and parents to use it when they had
one too many bad experiences with IE can send them Opera's way instead since
even though it is closed source and costs money, they actually seem to care
about their users.

I will probably get flamed for this, maybe even kicked off bugzilla, but I
really don't care.  I'm just so disappointed and disillusioned by the whole
thing I probably won't bother to ever waste my time contributing bug reports to
Mozilla again anyway.
Re comment 159:  Please remember is that the vast majority of the people
commenting on this bug don't represent Mozilla any more than you do.  Adam is
capable of requesting reviews for his patch and moving it towards checkin if he
wants to.

(Warning the user seems like a good idea to me, and sufficient for a significant
portion of Mozilla's users, although I'm not sure if the criteria need to be as
complicated as those in attachment 138901 [details] [diff] [review].  But that's not really relevant...)
This really is a tough bug.

Microsoft is ridiculous. They might has well have made their third workaround:
3) Use Mozilla


Correct me if I'm wrong but Mozilla is not as susceptible to this type of
spoofing because it correctly places a / when no path information is given. As
per the standard.

So in IE you can have this listed in the address bar:
http://www.yahoo.com
In Mozilla it always gets listed as:
http://www.yahoo.com/

So if you see a url:
http://www.bankofcanada.com________:safjklasfjqwfwqiojajlziojez@gotyourmoneyspoofer.com

Then you know that www.bankofcanada.com is not the host because the host is
always followed by a / in the standard and in mozilla.

I don't mean to imply that people still aren't fooled. But some education on the
users part is required. 

I got 6 MyDoom viruses before I manually updating Norton, I had to use my own
brain to figure out they were viruses.

Maybe someone should submit an RFC to change the URI syntax to not allow w and .
in the username.

Microsoft isn't fixing anything. Half the Internet still surfs with a pre IE6
browser.

I defintely sympatize with slice1900 it's been 2 years something should be done.

I'm not the leader here I just suggest ideas, even if some are out of the
(dialog) box.

We need the leader to make a decision and I'll live with it. 

On a personal opinion note. I need to stress again that username and passwords
are embedded so that dialogs are not prompted.
I completely agree with slice1900.  There are at least two patches listed on
this bug, both of them would be better than the status quo.

Note that MS hasn't disabled HTTP Basic Auth, they've just disabled that part of
the URL syntax which permits usernames to be sent as part of the URL.  That's
probably a third patch that should be considered in light of recent news, even
if it was considered too drastic earlier.

Two years is just stupid.  Like, *completely* stupid.  Any reason why the
2004-01-12 patch listed above can't be committed *today*??  If it's less than
completely optimal it can always be changed later, but two entire years with a
known-broken status quo is just abysmal.
A lot of people are missing the point here. The problem of hiding part of the
url has been fixed, mozilla now always shows the entire url of the site they are
viewing or will view if they click a link.

This bug is currently about helping the user understand what site they are on
when the url is somehow obscured. This doesn't fall into technical bugs, it
falls into social engineering, together with mailing users and *asking* them for
their creditcard number (which btw works just fine). This doesn't mean that we
can't or shouldn't do anything about it, but it does mean that we have to change
our way of thinking.

Most users won't know to look for /'es or @'s or any other character. Actually,
most users will even fall for urls such as:  http://www.paypal.com.evil.com/,
heck even http://www.paypal.evil.com/ would probably fool a lot of people.
Especially if you add a lot of crap afterwards so that you just skim over it.

No url-evilness-heuristics will be able to detect an url like that (sort of
rejecting any urls from "evil.com" of course ;-) ).

The only thing we could do is to emphasize the two last sections of the
domain-name, i.e. 'evil.com', somewhere where the user can clearly see it.
Either by marking that part of the url in urlbar itself, or displaying it in a
separate section somewhere in the UI.
Emphasising the last two elements of the domain name is no good -- unless the
entire useful part of the Internet is in the US.

I can't see that it'd be useful for Mozilla to hilight "com.au" or "ac.uk" at
the end of long URLs :-)

Just to reiterate:  there are two patches above which have been extensively
discussed, which address the social engineering aspect of the problem, which are
better than the status quo, and which have not been committed.

Is there any reason why one of them can't be committed *today* ?  Two years is
just embarrassing.

  - mark
Re comment #163 and comment #164, a URL ending in .com does not indicate that it
is a site in the USA. However, a URL ending in .us does indicate that it is a
site in the USA.

e.g. www.revenue.state.nh.us is a valid site name, and in this case is used by
the Department of Revenue in New Hampshire, USA.
Just to add to the previous comments, I know a number of .nz servers are
operated by nz companies but physically hosted in the US for bandwidth reasons.
I imagine the same goes for a number of other country TLDs
slice: the important thing is what we are going to do today and tomorrow. Not
many people have been affected by this attack, but it remains (IMHO) a serious
form of spoofing. If you simply have lost patience, close this bug, and I'll
re-file, so you don't keep getting the bugmail.

jonas: really long domain name spoofing has always been a problem, but it
appears that existing enforcement mechanisms have kept this limited. For one
thing, a hostmaster is direcctly on the hook for the contents of the subdomain,
if they refused to correct the situation, their delegation to their domain could
be unplugged. It is also a clear violation of trademark, so the law firms hired
to protect this jump on violations immediately.

The spoofing here is more complicated, because the spoofer points to a URL, and
web page ownership of often much harder to establish (for example, the system
could be hacked).
Jonas makes some really good points. This is a social engineering issue and none
of the solutions suggested will actually put the spoofers out of business.

The only way you can beat the spoofers is through education.

We can teach everyone how to parse the URL how it's defined in the RFC or we can
clearly place the hostname somewhere seperately and educate people to enter
information only at hostnames that exactly match what they are accepting.

Even that won't stop all the victims of spoofers. Some people are gullible and
will fall for anything.

Reality check:
Nothing we do here will make a big impact on spoofers. Mozilla has a small user
base and is used by mostly literate computer users.
Spoofers go for the stupidiest people. Which is why they spam people using AOL
and Hotmail. Cause a huge percentage of the least computer literate people are
customers of those companies.


On the MS issue. They are probably making the url return a syntax error so that
they don't have to fix this issue by getting rid of the stupid frame on external
hotmail links.
>exactly match what they are accepting.
exactly match what they are expecting.

I shouldn't post when I'm tired. Sorry for the spam.
Blocks: 232560
*** Bug 232567 has been marked as a duplicate of this bug. ***
A little question about the MS-"solution" I just wanted to add to Bug 232567.
What about URLs like:

ftp://www.mozilla.org:advdfbdfndfn@evil.com/evilpage.html

The user may still think he's at mozilla.org. OK, it's a ftp URL so some might
recognize the trick, but for sure not everybody will.

IMHO by removing support for http URLs with username/password they are only moving
the problem to another place.

just my 0.02¤
FYI, bug 228524 shows experimental code which displays only the hostname (and
SSL cert owner) in the toolbar.
I'm sure we will get this bug resolved now that Microsoft has given us a reason 
to do it. :-)

RFC 1738 says that the user:pass part of a URL "may be excluded". If we could go 
back to December 1994 and say, "hey, Tim, there's a hole" he would say, "okay, 
better make it very excluded." :-)

Being able to put user:pass in a URL was great in 1994 but it's not suitable in 
today's world. It's had it's day, it's done it's stuff, let's give it a nice 
present as a parting gift and move on folks. 

Just dropping it is simple, it's bulletproof, it'll unblock a bunch of bugs, and 
it's low-bloat. :-)

FYI, what MS does is wrong. They claim (to the user even!) that these URLs are
syntactically invalid, which is just plain wrong. They probably just were lazy
and completely dropped username/pw-support from their URL parser.

This isn't necessary at all. The *only* problem with the spoofing is the
*display* to the user, not the processing. Only when it's displayed can it
confuse the user. It's enough to change the display to remove the problem. There
are many possible solutions:
- don't display username/password at all in urlbar (and maybe statusbar)
- crop username after 5-8 chars (e.g. "joe.u...@mysite.com" and
  "www.m...@123.123.123.123")
- escape dots ("www%2emicrosoft%2dcom@123.123.123.123")
- a warning dialog in very suspicious situations
I use the http://user:pass@host/ syntax a lot for perfectly legitimate reasons.
And I copy URIs from the location bar all the time, expecting them to round 
trip. Neither of these use cases should be broken IMHO.

Escaping the dots solves the problem without breaking anything. That, to me, 
seems like the superior solution. It's also remarkably simple.
I could not agree more. Ben is right in the sense it's only a display problem,
and  escaping the dots seems has no drawback IMHO.
So does someone vote against this proposal ?
The problem with just escaping the dots is that the user may have gotten the URL
from elsewhere, and may not check the URL bar after visiting the link.  For
example, if they click on the link from a scam email, believing it's a link to
eBay they're clicking on, the email app won't display the URL with dots escaped,
and a user may not check the URL bar in their browser to make sure they are
going to the right place.  Further, by the time the page has loaded the damage
may already be done; for example if the scam site is stealing cookies in a
cross-site scripting attack, or exploiting a future bug in Mozilla.  I think a
user needs to know what site they're going to before Mozilla loads the page.

A cleaner way to handle this would be to display a password dialog the first
time a user visits each URL with a username and/or password in it.  The dialog
could simply say "The site www.shadysite.com has requested that you log in.",
with a spot for username and password below.  If they are provided in the URL,
they are filled in.  After the user has confirmed this once, it will not prompt
again in that session (much like HTTP auth dialogs work).  Confirming once
shouldn't be annoying, it clarifies to the user the site they're going to before
it loads, and it's not something that most mainstream Web sites use, so a user
would be surprised if they visited a link they thought was to eBay and this
dialog came up (hopefully making them read the dialog).  Much of this code must
already exist, since we can prompt for username and password for HTTP AUTH, and
track the information appropriately.
I vote strongly in favor of Scott's suggestion in #177!  A username of
www.ebay.com in this dialog should be a good tip-off to a user that something
fishy is going on.  That plus it allows the removal of the user/password from
the URL in the address bar if one chooses (hiding user/password in the URL bar
could be an option the user can set via prefs.)  

If the user also has the option of having Mozilla remember the user/password
like they do for simple auth, then it makes it a real non-issue for the end
user.  One final change could be made that compares the user/password passed in
the URL to one saved by the password manager.  If they match, don't display the
dialog (since we can assume if the user/password is in the URL that is the
user/password they intend to use.) They would see the dialog a couple of times
until they decided to check the "Use password manager to remember these values."
box.

IMHO, this is the most elegant solution I've seen yet without forcing us to read
the user's mind or the mind of the web site operator.
(In reply to comment #177)
> A cleaner way to handle this would be to display a password dialog the first
> time a user visits each URL with a username and/or password in it.  The dialog
> could simply say "The site www.shadysite.com has requested that you log in.",
> with a spot for username and password below.  If they are provided in the URL,
> they are filled in.  After the user has confirmed this once, it will not prompt
> again in that session (much like HTTP auth dialogs work).  Confirming once
> shouldn't be annoying, it clarifies to the user the site they're going to before
> it loads, and it's not something that most mainstream Web sites use, so a user
> would be surprised if they visited a link they thought was to eBay and this
> dialog came up (hopefully making them read the dialog).  Much of this code must
> already exist, since we can prompt for username and password for HTTP AUTH, and
> track the information appropriately.

yes, this would be trivial to implement.  i'm not sure it is what we want to do,
but it could certainly be easily done.

I'm torn up about this...  I'm interested in seeing us not breaking parts of a
long standing standard but here are some thoughts on my mind...

For "valid uses" of this syntax there isn't there a certain expection of
security around people put authentication on a host?  

If users are storing and passing around "user:pass" portions of
http://user:pass@host/path-directory-or-file aren't they violating that
expectation of security... 

Sure it makes things easier, but are we weighing this "easy of use" against the
pitfalls and side effects storing and passing around user:pass@host combinations
 in clear text, in addition to the other part of the "invalid/spoofing uses".

I've used this myself, and also set up servers to offer this as "weak security"
to provide a minimal level of security protection.  Maybe it's time for "minimal
security access" systems to be rethought...

I'm not sure if I understand the reasoning and rational for new dialog boxes
that prompt if the URL looks fishy...   don't we still prompt for user name and
password when a user hits http://host/path-directory-or-file when authenication
is set up?  If we disallow or remove "user:pass" we already have a dialog system
that we can use.


re: comment #180

The username and password is sent cleartext even if it is entered in the dialog
box.  The only difference is that it appears in the URL bar and history.  If a
web designer is actually seriously concerned about security, they shouldn't use
simple auth anyhow.

As far as already having a dialog goes, I agree.. we already have one we can
use. I'd like to see the developers use the suggestions in #177 and #178 for
(hopefully) a quick but comprehensive fix.  

Using the dialog doesn't make any statement that a site is "evil" and doesn't
require Mozilla to decide if sites are bad or not (which, IMHO, it shouldn't be
doing anyhow.)  It will work regardless of the visibility of the status bar or
URL bar.  It should be minimally invasive (possibly less so than normal use of
simple authentication.)  It won't be easy for the bad guys to trick or work
around.  And it shouldn't require constant updates to combat new tricks.  In
short it seems to be a great solution to me.
I still don't understand why we couldn't simply remove the username:password
part of the url when displaying it in the urlbar. We don't display username and
password there when the user logs in the normal way. And for good reason too, i
wouldn't want someone looking over my shoulder to be able to see what password
i've used. And the same somewhat applies to the username.

I will still be able to modify the url in the urlbar to go to a different place
in the website without having to re-login, for the same reason that i can when
the username/password were entered through a dialog rather then through a url.
This could also fix bug 130327.

Yes, it will break partially break Ians second usecase from comment 175; if you
copy the url and restart the browser then you can't simply paste the url to get
automatically logged in. However this is a security over feature concern, even
if we escape dots users will be fooled by urls like
http://www_microsoft_com%20lotsofcrufthere:passwd@evil.com.

And when displaying the url in the statusbar we could display:
http://evil.com/  (username="www_microsoft_com lotsofcrufthere"
password="passwd"). That value won't ever be copied or edited or parsed anyway.
> FYI, what MS does is wrong.

Perhaps what MS is going to do is partly right but as usual just not quite. What 
they mean is, "Sorry, the syntax is not supported for security reasons."

Remember psychology. A lot of what we perceive is what we expect. We're talking 
about a situation where someone believes they have correspondence from someone 
they trust. What we see is coloured by expectation. Plus untrained users have 
learned that computers cry wolf all the time. I think MS has correctly IMHO 
worked out that once someone has started down that path some seriously strong 
medicine is needed, and display hardly comes into it.

> This isn't necessary at all

...from a technical point of view, but it might be from a human-computer 
interaction point of view. Besides, from a technical point of view, it's just an 
optional part of the syntax and we can resolve the bug by making it even
more optional. :-)

(In reply to comment #173)

> RFC 1738 says that the user:pass part of a URL "may be excluded". If we could go 
> back to December 1994 and say, "hey, Tim, there's a hole" he would say, "okay, 
> better make it very excluded." :-)

and RFC 2396 changes the definition of "user:password" to "userinfo" and says
that's not recommended to use the "user:password" format in the "userinfo"
field, while RFC 2616 says that the "userinfo" part just isn't there in http
uri, so for once microsoft is doing the "right thing"(tm) wrt RFCs.
Why not use syntax highlighting in the address bar? Either the foreground/font 
color or the background color could be used to make the actual domain name 
clear to the user.
For example, the user:password part could be in red, while the domain would be 
in bold. 

The first time the user would encounter this type of url, a popup might appear 
to explain what is going on. The popup would have a "never display again" 
option...
I think that the news of changes to MSIE does affect decisions on this bug a
little. If MS does enact these changes, then this part of the standard will
likely fade away in time as I can't see anyone wanting to implement a feature
that is not used by the primary web browser. So an opportunity to re-cap on the
goal:

GOAL: We want to make it hard/impossible for a user to be duped into clicking 
on a spoof link and arrive that they think is a legitimate site when it isn't.
The primary vector for attack is by sending the user an email. A secondary
vector would be by a link on a web site.

And here are some facts (feel free to disagree, although I have tried to remain
impartial and objective here so please only argue if there is a point to be made!):

1). Broadly, all users are at risk of this since all users are able to follow
hyper-links. Users at greater risk are those who are less technically aware 
and/or less security aware. This group represents that majority [of internet users].

2). There are users who currently make use of this user authentication feature.
They are the minority.

3). It would appear that MS has taken the view that removing this feature
altogether who make their product more secure for the majority. Where people are
using this feature, there are work-arounds.

MY VIEW: I think removing this feature now would be premature. If MS removes
this feature altogether then it might give Mozilla an opportunity to gain a
foot-hold in certain "verticals".

However, if we leave the feature in whilst MSIE does not suffer the same
"vulnerability" then that might place us on a back-foot.

In the real world this probably doesn't represent much risk as Mozilla users are
in the main more technically literate than MSIE users (I don't mean that in a
disparaging way to MSIE users).

Why don't we simply make user-authentication by URL an optional feature?
And why don't we have it disabled by default?

What I don't know is why and/or how this feature is being used. And I don't know
what percentage of the user base this represents.

If you use this feature, would you object to it being an option that you need to
enable? You'd only have to do it once! If this was acceptable, this would (I
think) resolve everything -- all parties would be happy. Surely?! :)

ps. Apologies for stomping over previous suggestions re dialogs/modifying the
address bar, etc. A week ago I had different opinions, but now, given MS's
stance, I think this re-evaluation is a useful exercise.
In the year I have been tracking this bug, the ones from the past few days have 
impressed me. I am unsure whether the driving force is the age of this bug or 
Microsoft's decision to axe this type of urls.

Just a few (semi-recycled) ideas...

1. Display the server address in the status bar. For example, if the link is to 
http://hotmail.com@evilsite.net/hotmail then http://evilsite.net/hotmail will 
be shown in the stausbar. This eliminates the fake garbage added to spoof urls.
Coloring the sections of the url is useless, since the spoof logins are too 
long to show the entire string.

2. Displaying a dialog with the server, username and password. Give the user 
the info right up front. Even better, put the "Continue" button in a funny 
spot, to make the user stop and read the dialog. The Cancel/Stop button must 
have focus by default and be in an obvious location.

3. As I have stated numerous times before, bury the no-dialog option deep 
within the preferences. The average joe cannot be trusted with permenantly 
dismissing dialogs.

4. Adding symbol similar to one shown in the "Screenshot of styled page (this 
page, in fact) - no mockup" attachment. With one change, to maintain the flow 
of text, make the image height match the height of the text. Clicking the 
symbol brings up information about spoof urls, and how to tell if the link is 
legitimate or a fake.

5. Automatic blocking if the link contains the %00&#1; IE exploit. No 
legitimate site would use this type of link. I thing everyone will agree to 
this.
> I still don't understand why we couldn't simply remove the username:password
> part of the url when displaying it in the urlbar.

I frequently type addresses into the address bar including user:pass info and
then once i've checked it works, copy it. The above would break that.


> [dialog]

Opera has a dialog for this. It's quite annoying. I recommend against it.


> http://www_microsoft_com:.../

So also escape underscores. Escape anything you have to -- everything except US
ASCII, if you have to.


> [other sources] [future bugs]

Then those other sources are insecure. Let's not try to fix all the world's
problems -- fixing our own is enough. 
Oh and anothe thing. Dialogs don't work. It is a recognised fact of UI design
that real users (those we're trying to "save") have one reaction to dialogs and
one alone: get rid of it by any means possible, and under no circumstances read
it. So I strongly urge the "dialog" camp to revise their opinion. :-)
[re-use password dialog]
> A username of www.ebay.com in this dialog should be a good tip-off to a
> user that something fishy is going on.

If you are not familar with HTTP auth and just quickly glance over the dialog,
you may just read "www.ebay.com" and think "OK, eBay, that's what I expected,
why did this stupid dialog come up now? Go away.". For this reason, IMHO any
(warning) dialog should *not* display the credentials at all.

> while RFC 2616 says that the "userinfo" part just isn't there in http
> uri, so for once microsoft is doing the "right thing"(tm) wrt RFCs.

Wrong. See comment 148.

> from a technical point of view, it's just an optional part of the syntax and
> we can resolve the bug by making it even more optional.

It's optional in the sense that not every URL must have that part. That doesn't
mean that the software may bail, if it exists.

> Why not use syntax highlighting in the address bar?

Already discussed above.

> Why don't we simply make user-authentication by URL an optional feature?
> And why don't we have it disabled by default?

We have too many prefs already.

> put the "Continue" button in a funny 
> spot, to make the user stop and read the dialog.

On the backside of the monitor?
> > I still don't understand why we couldn't simply remove the username:password
> > part of the url when displaying it in the urlbar.
> 
> I frequently type addresses into the address bar including user:pass info and
> then once i've checked it works, copy it. The above would break that.

First of all i think a fairly small part of the userbase does this. Small enough
that security of the larger userbase is more important.

Second, just copy before hitting enter. Problem solved :)

> > http://www_microsoft_com:.../
> 
> So also escape underscores. Escape anything you have to -- everything except 
> US ASCII, if you have to.

That'd be a bit nasty if we did for all of the url. Though i suppose we could do
it only for the username:password part.

If Microsoft wants to drop the userinfo part of the url that is their problem.
As long as userinfo is part of the RFCs that describe URLs (and the definitive
RFC on that currently is RFC 2396) we do and we should implement it. If MSIE
drops the support I would see it as a distinctiv advantage of Mozilla that we
still do.

Make the url in the status-bar use syntax highlightning that clearly marks
potentially dangerous parts or if the link is already clicked, let the page
flash with a red background to warn the user or something similar.
(In reply to comment #191)
>>
>> I frequently type addresses into the address bar including user:pass info and
>> then once i've checked it works, copy it. The above would break that.
> 
> First of all i think a fairly small part of the userbase does this. Small 
> enough that security of the larger userbase is more important.

Nice to know you don't consider me an important user...


> Second, just copy before hitting enter. Problem solved :)

That wouldn't catch the normalising of the URI which is what I'm really after.


> That'd be a bit nasty if we did for all of the url. Though i suppose we could 
> do it only for the username:password part.

This proposal has always only mentioned doing it for the username part. Note
that this doesn't affect most legitimate users at all, and doesn't annoy or harm
or confuse other legitimate users. Only illegitimate users are likely to get in
any way confused or worried, and that is exactly what we want to happen.
I also vote for Comment #177.  It's very elegant, doesn't add any more types of
dialog boxes, behaves like other authentication mechanisms, and informs the user
BEFORE the page is loaded.  Most importantly, it makes no additonal decisions on
whether a URL is valid or not, and does not change other parts of the UI.

Although we'd like an 'idiot-proof' environment, as we know, only an idiot would
want to use it.

This mechanism displays all the information that a user requires to make an
informed decision, and uses an already established mechanism.  What the user
decides to do is up to them.  I believe in informing the user, but not babying them.

As others have stated above, I believe that fixing this bug is very important to
the continued adoption of Mozilla as a viable browser.  Hopefully this can
happen soon.

Also, given the length of time this feature has been available, realize that
taking it out now will result far more negatively than when MNG was removed. 
Perhaps something can be done for links that come from other programs (like
e-mail) but for links that I put in myself, I want the user/pass stuff to be
handled and saved properly, even if it doesn't show up in the bar.  These types
of links are commonly used in academia when it doesn't matter if anybody within
the university knows the password; they're used as a crude way to keep outsiders
from stealing course content.  I've seen similar approaches used in companies
providing temporary download sites for customers (and a lot of the time, the
username is going to contain a domain-- the domain of the customer)  Also, while
it might require a slight bit more technical ability for the attacker, a DNS
name like www.hotmail.com.some.other.junk.evilsite.com is still possible, so
this really won't help the matter that much.  I wonder how much extra bloat
parsing URLs like this is going to incur.  I don't think this is going to help
much-- we've got MyDoom running around all over the place, even without really
spoofing anything; people open the attachments anyway.
Ben. Good work I agree with your GUI designs and posts. One suggestion is to
leave the www. part.

GOOD IDEA:
I have a good idea that takes from other ideas suggested. Please someone attempt
to pick it apart.

-We can remove the username:password from the url bar by default. But still
allow the information to authenticate as if it were not removed.
-This means no functionality or automated scripts would be broken. Regular users
to websites will not be disturbed in any way and website owners will remain
confident their links will still work.
-For those that like to copy and paste the urls WITH the username:password we
have a simple boolean option in about:config. This satisfies people who manually
enter the information and wish to copy and paste it. 
I 've been talking to many people in our company, with web-tech skills varying
from very simple web users (like accounters) to really experinecd ones
(programmers who are living by rewriting IE in customize some our kiosk
products). They all agree if:

1. username/password will be deleted (actually hidden) from being displayed in
URL, but...

2. there will be some sort of alert icons, which will be highlighted immidiately
if the current URL has a hidden username/password. 

3. And like with popup blocking alert icon, if you click on it it will dispaly
the username/password if any hidden.

Such solution will improve security in two areas:

A. it will avoid confusing users by spoofing the actual URL - very important for
no-experienced users;

B. it would avoid behind-the shoulder guests to read the actually impirtant
passwords in the URL string - very important when computer is in the public place.

Our IE programmers told that they would create a similar solution for our
cutomized IE based browser if the boss would require it. ... ehhh, if only our
boss would require to move to Mozilla based customized browser ...
Here is a case we have to deal with:

   http://ddkg29egb.da.ru/

Turn off popup blocking and visit that site. Imagine you actually followed the
following (invalid) URI in your non-Mozilla mail client, which incorrectly
normalised the escapes before passing it to Mozilla [1]:

   http://www.citibank.com:80@%64%64%6b%6729%65%67%62%2e%44%61%2e%52%75/verify

Things to note:
   1. It shows a legitimate URI in the background.
   2. It shows a window in the foreground with no easy way to determine the 
      hostname.

The escaping idea, together with putting the hostname in the window caption when
the location bar is hidden (much like we put [Javascript Dialog] in dialog
captions), would, I think, take care of this case.

[1] Actually Mozilla itself is interpreting the escapes in cases like the above
in certain cases. If we do those in any cases other than links then that should
be filed separately. (It's ok to do it for <a> links since we show the hyperlink
unescaped in the status bar.)
(In reply to comment #186) 
[Warning : potentially offending contents]

> What I don't know is why and/or how this feature is being used. 
Well, see http://www.ultrapasswords.com/ for example :-) 

> And I don't know what percentage of the user base this represents.
If you ask "Who regularly visit porn sites", you might be answered "no-one". But
you know Mozilla already is the preferred browser for erotic websites fans.

Please note that I don't make any judgement whether getting/distributing
passwords to enter X-rated websites is legit or not.
Adam: (per your request in comment #126)

Comments on patch:

+    PRBool isHttp = PR_FALSE;
+    PRBool isHttps = PR_FALSE;
+    aURI->SchemeIs("http", &isHttp);
+    aURI->SchemeIs("https", &isHttps);
+    if (!isHttp && !isHttps)

Are we planning on supporting any scheme that has user:pass? If so, we need to
add "ftp:" ?

I like what I see, especially the way spoofing is measured as a "dubiousness"
value that can be incremented by various evaluations and a threshold (currently
<2) controls the usage of a warning. 

As I've stated in #120, I think we should flag any presence of a "." (or perhaps
2 periods), in other words, anything that could spoof a legitimate FQDN (domain
name). The current focus of spoofers is brand name portal sites, but anticipate
forged email to attack corporate intranets next (mcom.com, server.mcom.com"). 

What will it take to check something in? Who needs to approve this, and what
level of consensus is needed?

Adam, you wrote the patch, do you want to take ownership, and I'll take QA?
IMHO the current patch is way over-engineered, especially considering the
arguments against any kind of dialog box (they are annoying and users don't read
them, whatever they say), and the proposed alternatives (escape dots in the
username and password part, place the hostname in the title bar if the location
bar is hidden).
Excellent point.  Let's spend another two years talking about it instead of
fixing the security vulnerability, eh?  That way we can be completely sure that
we'll get a 100% perfect fix the very first time, without all that messy
stuffing-about with CVS afterwards.

Sigh.
*or* we could spend time on half-way implementing features which bloats the code
and makes it more bugprone, which will introduce even *more* security bugs.
Yeah, that sounds good.

No disrespect to Adams patch, it's always nice to see implementations of ideas,
makes for a much better discussion.
I have spent the last few hours reading this bug, and there are many ideas in
here that I believe would work.  As far as the escaping the username and
password in the URI idea goes I have an additional comment (Not that I'm
advocating this solution as I believe other solutions go further).  Surely the
*whole* of the username and password could be escaped without breaking anything,
and infact leaving things more secure as the over the shoulder password taking
would be a lot more difficult.  That way an average user *who looks at the
addressbar after navigating to a page* will not be fooled by
http://www.citibank.com:80@www.evildomain.com as instead of looking like 
http://www%2ecitibank%2ecom:80@www.evildomain.com which is still similar it will
look like
http://%77%77%77%2e%63%69%74%69%62%61%6e%6b%2e%63%6f%6d:%38%30@www.evildomain.com


May that my opinion is unnecessary here but it seems that it's not clear if a
username and password in http urls are valid or not. I think all people will
agree that the RFC 2616 and RFC 2396 are the valid and required RFCs to
interpret the HTTP URL syntax. I think some people misinterpret some parts.
(Maybe I also misinterpret those RFC's because I'm also not firm with them.)

The question is "is the definition of http_URL valid and contains it only a
hostname" in
1) RFC 2616; 3.2.2 http URL:
   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.
   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

In my opinion: definitive 'yes'.
A _valid_ http url _could_ not have a username and/or password.

Motivation:
2) RFC 2396; 1.2. URI, URL, and URN
   In other words, the URI syntax is a superset
   of the syntax of all URI schemes.

In other words RFC 2396 can not describe an individual scheme (like http). IMHO
it only describes a template.

3) RFC 2396; 1. Introduction:
   This document updates and merges "Uniform Resource Locators"
   [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order
   to define a single, generic syntax for all URI.  It excludes those
   portions of RFC 1738 that defined the specific syntax of individual
   URL schemes; those portions will be updated as separate documents, as
   will the process for registration of new URI schemes.

Other documents (RFCs) could define the syntax of individual URL schemes, like
RFC 2616 does in citation 1). I have not verified it, but I think the
restrictions and specifications made by the http_url definition does not break
this generic syntax, and they valid because they are updates for this "http"
(=individual) URL scheme.

Some argumented that RFC 2396 has defined 'userinfo' for URI in
4) RFC 2396; 3.2.2. Server-based Naming Authority
(See comment 149 for citation)

That is wrong! RFC 2396 describes a superset, not a specific scheme.
It defines that URL schemes could (NOT MUST) have the 'userinfo'.

5) RFC 2616; 3.2.1 General Syntax:
   For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," RFC 2396

I think this refers to RFC 2396, if (and only if) something in the URL
description of the RFC is not clearly described or defined.
This explicit fulfilled for some definitions:

6) RFC 2616; 3.2.1 General Syntax:
   This specification adopts the
   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
   "host","abs_path", "rel_path", and "authority" from that
   specification.

As described in comment 151:
'host' is defined in RFC 2396 and does not include 'userinfo', so a _valid_ http
url _could_ not have a username and/or password.

Other interesting drafts and RFCs are
*) RFC 2718 (Guidelines for new URL Schemes)
*) RFC 2732 (IPv6 Literal Addresses in URL's) 
   This is an URL definition update for RFC 2396
*) draft of HTTP AUTH URL 
   This includes an update for RFC 2396 with 'userinfo' in http URL's:
   http://www.ietf.org/internet-drafts/draft-melnikov-http-auth-url-00.txt
(In reply to comment #205)
> The question is "is the definition of http_URL valid and contains it only a
> hostname" in
> 1) RFC 2616; 3.2.2 http URL:
>    The "http" scheme is used to locate network resources via the HTTP
>    protocol. This section defines the scheme-specific syntax and
>    semantics for http URLs.
>    http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
> 
> In my opinion: definitive 'yes'.
> A _valid_ http url _could_ not have a username and/or password.
> 
> Motivation:
> 2) RFC 2396; 1.2. URI, URL, and URN
>    In other words, the URI syntax is a superset
>    of the syntax of all URI schemes.
> 
> In other words RFC 2396 can not describe an individual scheme (like http).
> IMHO it only describes a template.

This is basically the same logic that Microsoft used in eliminating the
username:password from http/https requests with the recent February security
patch to IE6 SP1.  See the section labeled CAN-2003-1025 at
http://www.microsoft.com/technet/security/bulletin/MS04-004.asp for details.

That being said, instead of dropping support entirely, I personally would be in
favor of comment #177.  Once per session, put up a prefilled in username
password dialog box when any username:password URLs (http, https, ftp, news,
etc) are requested.

However something needs to be done NOW.
Sorry, not a programmer, so can't comment on the patch. Also, started zoning out
while reading 180+ comments so apologies if these suggestions have already been
made.  

1. If the location field is hidden, definitely show a dialog box.  By the way, I
personally will miss the warning if it's in the status bar or location box.

2. Suggestion for dialog:
[! symbol]
You are about to go to "[de-escaped domain in big bold letters]".  Do you really
want to do this?
Buttons:
Continue
Stop
Check box: Remember this decision

3. Suggestion for [de-escaped domain]:

<preceding node>\.[a-z][a-z][a-z]+$
<2nd preceding node>\.<preceding node>(\.[a-z][a-z])+$

4. Please, no flashing of any kind.  Violates W3C accessibility guidelines.

5. %01 has also been listed as a hack in at least one article I read (in
addition to @ and %00).
For those who don't have or use Internet Explorer 6 or Windows XP: 
The Windows Update patch for IE6 which is mentioned above has arrived and is
causing valid URLs to return "invalid syntax error".
(In reply to comment #208)
> For those who don't have or use Internet Explorer 6 or Windows XP: 
> The Windows Update patch for IE6 which is mentioned above has arrived and is
> causing valid URLs to return "invalid syntax error".

Could you give an example of a valid URL that returns "invalid syntax error". 
Something other than http://user@password:www.sample.com, of course; based upon
the reasoning used in comment #205, that wouldn't necessarily be a valid http URL. 

They should be posted so that whichever scheme that is eventually adopted for
Mozilla doesn't also trip up on them.
As far as I know it's pretty obvious that username and password are valid
according to RFC. If not then why would Mozilla and IE support them in the first
place. But I'll leave that final decision for those capable of understanding the
poorly worded RFC english from the W3.

Anyways, to answer your question Kelley.

http://@www.microsoft.com/
http://user@www.microsoft.com/
http://user:pass@www.microsoft.com/
http://www.microsoft.com@/
http://www.microsoft.com@
http://www.microsoft.com:80a/

All of the above return invalid syntax error.

@ before host will trip the error
non numberic port will trip the error.

http://www.micro%20soft.com/
This did not return invalid syntax it returned Cannot find server.

(In reply to comment #152)
> RFC 2616 describes the HTTP-protocol, NOT HTTP-uris. RFC 2616 delegates that to
> RFC 2396 or to RFC1738 which has a specific section about http-uris. 
> 
> In my opinion RFC 2616 just defines a "simple" version of http uris as it was
> needed to explain the http protocol. RFC 2396 is the definitiv resource for URIs
> and RFC 1738 makes clear that username:password is possible (Section 3.1):
> 
>    ...
>    While the syntax for the rest of the URL may vary depending on the
>    particular scheme selected, URL schemes that involve the direct use
>    of an IP-based protocol to a specified host on the Internet use a
>    common syntax for the scheme-specific data:
> 
>         //<user>:<password>@<host>:<port>/<url-path>
> 
>    Some or all of the parts "<user>:<password>@", ":<password>",
>    ":<port>", and "/<url-path>" may be excluded.
>    ...
> 
> And section 3.3:
> 
>    ...
>    An HTTP URL takes the form:
> 
>       http://<host>:<port>/<path>?<searchpart>
> 
>    where <host> and <port> are as described in Section 3.1.
>    ...

You 're NOT right, because RFC 1738 says:

3.3. HTTP

   The HTTP URL scheme is used to designate Internet resources
   accessible using HTTP (HyperText Transfer Protocol).

   The HTTP protocol is specified elsewhere. This specification only
   describes the syntax of HTTP URLs.

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
   string. The <path> is optional, as is the <searchpart> and its
   preceding "?". If neither <path> nor <searchpart> is present, the "/"
   may also be omitted.

   Within the <path> and <searchpart> components, "/", ";", "?" are
   reserved.  The "/" character may be used within HTTP to designate a
   hierarchical structure.

So they have made crystal clear that a username and password is NOT allowed in
HTTP URL....
I think that this is the definitive resource for the definition of the HTTP
URLs, so we should simply follow MS way and say to the user that the sintax on
not valid....(Althought I'm not that happy in saying that MS has done the right
thing this time...)
(In reply to comment #152)
> RFC 2616 describes the HTTP-protocol, NOT HTTP-uris. RFC 2616 delegates that to
> RFC 2396 or to RFC1738 which has a specific section about http-uris. 
> 
> In my opinion RFC 2616 just defines a "simple" version of http uris as it was
> needed to explain the http protocol. RFC 2396 is the definitiv resource for URIs
> and RFC 1738 makes clear that username:password is possible (Section 3.1):
> 
>    ...
>    While the syntax for the rest of the URL may vary depending on the
>    particular scheme selected, URL schemes that involve the direct use
>    of an IP-based protocol to a specified host on the Internet use a
>    common syntax for the scheme-specific data:
> 
>         //<user>:<password>@<host>:<port>/<url-path>
> 
>    Some or all of the parts "<user>:<password>@", ":<password>",
>    ":<port>", and "/<url-path>" may be excluded.
>    ...
> 
> And section 3.3:
> 
>    ...
>    An HTTP URL takes the form:
> 
>       http://<host>:<port>/<path>?<searchpart>
> 
>    where <host> and <port> are as described in Section 3.1.
>    ...

You 're NOT right, because RFC 1738 says:

3.3. HTTP

   The HTTP URL scheme is used to designate Internet resources
   accessible using HTTP (HyperText Transfer Protocol).

   The HTTP protocol is specified elsewhere. This specification only
   describes the syntax of HTTP URLs.

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
   string. The <path> is optional, as is the <searchpart> and its
   preceding "?". If neither <path> nor <searchpart> is present, the "/"
   may also be omitted.

   Within the <path> and <searchpart> components, "/", ";", "?" are
   reserved.  The "/" character may be used within HTTP to designate a
   hierarchical structure.

So they have made crystal clear that a username and password is NOT allowed in
HTTP URL....
I think that this is the definitive resource for the definition of the HTTP
URLs, so we should simply follow MS way and say to the user that the sintax on
not valid....(Althought I'm not that happy in saying that MS has done the right
thing this time...)
It has already been mentioned that the syntax "userinfo@host:port" is allowed in
rfc 2396 (which updates rfc 1738) - see comment #149. So it's not a syntax
error, it's merely not a recommended place to put a username/password. And it is
still occasionally (?) used, which is a reason not to abolish support completely. 
Although I imagine nowdays illigitimate use occurs more frequently than
legitimate use? 
Personally, I'd feel OK with an authentication dialogue and scrapping the
userinfo once submitted.
(In reply to comment #210)
> http://@www.microsoft.com/
This is an invalid http URI.
> http://user@www.microsoft.com/
Ditto.
> http://user:pass@www.microsoft.com/
Ditto.
> http://www.microsoft.com@/
Ditto.
> http://www.microsoft.com@
Ditto.
> http://www.microsoft.com:80a/ 
Ditto.
> 
> All of the above return invalid syntax error.
> @ before host will trip the error
> non numberic port will trip the error.

As well they should.  As noted previously RFC 2616 overrules the generic URI
syntax specified in RFC2396 to be:

 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

It explicitly retains the RFC2396 definitions of "host" and "port".  Essentially
"host" can only be alphanumeric or "-" or "." while "port" can only be digits.

Furthermore, where the userinfo syntax is defined from RFC 2396 it even notes
this exception: "Some URL schemes use the format "user:password" in the userinfo
field. This practice is NOT RECOMMENDED, because the passing of authentication
information in clear text (such as URI) has proven to be a security risk in
almost every case where it has been used."

Please note the word "SOME".  To be clear, neither the http nor https schemes
use that format.

> http://www.micro%20soft.com/
> This did not return invalid syntax it returned Cannot find server.

A quibble/bug with their browser.  The syntax *is* wrong, but the error message
is gets the point across.

To reiterate the main, Microsoft is correct -- user:pass is not allowed in http
and https URIs.

Finally I don't why we are even argueing about this fact under this bug.  The
place to question this is on the HTTP-workinggroup mailing list, where
unsurprisingly it came up this week.  The subject was basically closed by the
author of RFC 2616 and chairman of the HTTP-workgroup.

http://lists.w3.org/Archives/Public/ietf-http-wg/2004JanMar/0006.html

'That form of URI has been officially deprecated by the IETF for over 9 years. 
The HTTP standard doesn't even allow it for "http" URIs.'
 --Roy T. Fielding

Therefore, the proper thing to do is to delete support for cleartext URL
authentication from http/https.  If Mozilla doesn't wish to do that then at the
VERY least implement comment 177 and put up the password dialog box.
As somebody who's Firebird home page uses a user@ URL, I have to ask that we do
not follow MS's example of dropping support entirely.  (Even if it is
technically correct per the RFCs)  I was even against any kind of pop-up, but
after seeing a spoof/scam attempt in real life I feel a little differently.

For an example of why adding something to/near the address bar or adding
something to the status bar doesn't work, see this page:
http://www.dce.k12.wi.us/tech/urlspoofing.html

Unless we drop URL authentication entirely, nothing we do is going to keep a
user from clicking on that link (or pasting it) if they don't know about
spoofing.  Look at the URL listed and look at the screenshot.  In the
screenshot, only the little window (with no address bar or status bar) is using
spoofing.  The URL in the bigger window is obscured, but that doesn't matter...
that URL is completely legit.

Even choosing to right-click and select View Page Info only gives something like
this: http://www.dce.k12.wi.us/tech/images/ccsafety/page-info.jpg  (The only
indication of where the page is reads URL:  http://www.citibank.com:23 in this case.

So two things are clear from this example:
1) A pop-up of some kind is neccessary.  Even fairly educated users could get
tricked with this kind of spoof.
2) The "View Page Info" dialog should probably either strip user/password from
the URL or should add a "Host:" entry.

I'm still in favor of a standard authentication dialog (or perhaps slightly
modified) which pops up for any URL containing user or user:password info. I
would like to see it keep the "Use Password Manager to remember these values"
checkbox... and once saved not display the dialog any more for that URL.  This
last part, while not actually neccessary, would significantly lower the
irritation factor for those of us who actually do use URLs like this.

By the way, getting rid of plaintext auth in the URL is actually not a 100% fox
for this particular example.  The scamster could use an initial link like &lt;a
href="someurl"&gt;http://www.citibank.com/emailconf.html&lt;/a&gt;  Once they
visit the link, the only indication something is wrong would be to View Page
Info on the 2nd window.  Since they didn't use spoofing, no fix we do for this
bug would prevent it.

So, my vote is (again) for <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=122445#c177">Comment #177</a>
with the additional Password Manager changes from <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=122445#c178">Comment #178</a>

NOTE: The link used by the scamster initially was
http://www.citigroup.net:6F85YwvH8@daqq1fd9c.Da.rU/?uCzpNb with nearly
everything after ".net:" URLencoded (except the @.) It looks like the server
operators have removed that page now.
Just so everyone knows, whatever applies to HTTP applies to HTTPS.
From RFC 2818:

2.4.  URI Format

   HTTP/TLS is differentiated from HTTP URIs by using the 'https'
   protocol identifier in place of the 'http' protocol identifier. An
   example URI specifying HTTP/TLS is:

     https://www.example.com/~smith/home.html
Please disregard my RFC comment in comment #210 I no longer believe what I said
there and have read over several sections from several RFCs and wish to weigh in.

RFC 1738 - Uniform Resource Locators
RFC 1808 - Relative Uniform Resource Locators

RFC 2396 - Uniform Resource Identifiers
-this RFC updates and merges the two previous RFCs
-As of the finalization of RFC 2396 section 3.3 from RFC 1738 still applies
because of the below paragraph in Section 1 of RFC 2396

   This document updates and merges "Uniform Resource Locators"
   [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order
   to define a single, generic syntax for all URI.  It excludes those
   portions of RFC 1738 that defined the specific syntax of individual
   URL schemes; those portions will be updated as separate documents, as
   will the process for registration of new URI schemes.  This document
   does not discuss the issues and recommendation for dealing with
   characters outside of the US-ASCII character set [ASCII]; those
   recommendations are discussed in a separate document.

-Section 3.3 from RFC 1738 which makes clear no username and password are
allowed for HTTP URI.
-RFC 2396 which is the current definitive document on URI states that it is a
superset and not all URI include all parts of the superset

From RFC 2396
   This paper describes a "superset" of operations that can be applied
   to URI.  It consists of both a grammar and a description of basic
   functionality for URI.  To understand what is a valid URI, both the
   grammar and the associated description have to be studied.  Some of
   the functionality described is not applicable to all URI schemes, and
   some operations are only possible when certain media types are
   retrieved using the URI, regardless of the scheme used.

-RFC 2396 promises that section 3.3 of RFC 1738 will be updated in the future by
another RFC.


RFC 2616 - Hypertext Transfer Protocol
-This RFC replaces section 3.3 of RFC 1738

**** SUMMARY ****:
RFC 1738 and 1808 have been completely replaced from a HTTP standpoint by RFC
2396 and RFC 2616
I recommend any further posts take this into consideration and do not quote from
the old RFCs anymore.
Also previous to RFC 2616 it is clear that no username and password were allowed
(section 3.3 of RFC 1738). Any argument for username and password in HTTP URI
must use RFC 2396 and RFC 2616 to show that post RFC 2616 username and password
were added to the HTTP URI scheme.
From:
http://lists.w3.org/Archives/Public/ietf-http-wg/2004JanMar/0006.html

>That form of URI has been officially deprecated by the IETF
>for over 9 years.

Can someone find a reference to validate that statement?
To determine a valid HTTP URI we need two RFCs
RFC 2396 and RFC 2616

RFC 2616 takes the following definitions from RFC 2396:
URI-reference
absoluteURI
relativeURI
port
host
abs_path
rel_path
authority


Section 3.2 of RFC 2616 states:
   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs
   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

These definitions are from RFC 2396
  host          = hostname | IPv4address
  hostname      = *( domainlabel "." ) toplabel [ "." ]
  port          = *digit

Which means host and port can be empty.

RFC 2616 states that abs_path is a Request-URI as specified in Sectin 5.1.2
Section 5.1.2 allows authority for the CONNECT method. 
authority has a long definition but basically it means you can use
username:password@host

By using the http scheme the following would be a VALID Request URI:
CONNECT http://username:password@www.mozilla.org/index.html HTTP/1.1

By using the http scheme the following would be a INVALID Request URI:
GET http://username:password@www.mozilla.org/index.html HTTP/1.1

Unfortunately the CONNECT method is not defined in RFC 2616 and is just referred
to a work in progress:
  [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
        servers," Work in Progress. [jg647]


Problem:
The Mozilla Location bar as it works now does not just accept an http get
request it accepts any URI and translates it to a client request internally
based on assumptions of what a user expects. 

Users do not specify their request method and mozilla currently accepts valid
URI syntax.

Possible Solutions:
Mozilla can take a partial request such as:
http://www.mozilla.org
and convert it to at least these four proper requests:

GET http://www.mozilla.org/ HTTP/1.1
or
GET / HTTP/1.1
Host: www.mozilla.org
or
HEAD http://www.mozilla.org/ HTTP/1.1
or
HEAD / HTTP/1.1
Host: www.mozilla.org

Similarly mozilla can take a partial CONNECT request:
http://username:password@www.mozilla.org
and convert it to a proper GET request using the authorization header:
GET / HTTP/1.1
Host: www.mozilla.org
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Read more on the authorization header at RFC 2617

CONCLUSION:
The decision is up to us.
Re-read comment 211 (especially the part that quotes the rfc saying "No user
name or password is allowed"). Rfc 1738 is dated December 1994 so that's where
the nine years comes from.

IE's change to stop supporting this format has broken PayPal links. Given MS's
marketshare and the clout of thousands of merchants accepting PayPal who want
their money we should probably hang on a while longer and see how this settles out.
Daniel RFC 1738 no longer applies.
I know 1738 has been superseded, but in comment 218 you asked for documentation
for the "deprecated...for over 9 years" comment: rfc 1738 came out nine years ago. 
The newer RFCs aren't as explicit on the issue, but neither can they be read as
reversing course from 1738. The browser community has ignored this aspect of the
RFCs for over nine years as stated in the message you linked to.
Ok, I understand what you are saying. Thanks for the clarification. :)
Setting this bug to blocking 1.7a+. Adam, can you help chase down reviews for
this patch.
Flags: blocking1.7a? → blocking1.7a+
Blocks: 157354
Blocks: 228612
Adam: I hope you don't mind, I've changed the ownerships.

I'm going to ask again, that people stop commenting on issues that should be
discussed in other bugs. I'm trying to summarize all the spoofing issues in one
document and get the other issues broken out.

a couple bugs worth looking at:

Bug 233865 - very long domain names that confuse users
Bug 232567 - remove support for userpass (aka Microsoft solution) -or- warn on
bogus userpass info (this bug is drifting as well!)
Bug 233340 - only password manager should store URL passwords
Assignee: security-bugs → adamlock
QA Contact: adamlock → benc
Summary: Spoof prevention: Warn if username/password in link (url) looks like a hostname → URL: Spoof : Dialog warning if userpass looks like a hostname
Whiteboard: spoof → spoof [comment only about the patch implementation]
Target Milestone: --- → mozilla1.7alpha
benc, the discussion in this bug is broader than a dialog, in fact many people
(incl. developers) voted against a dialog. Removing "dialog" from summary.
Summary: URL: Spoof : Dialog warning if userpass looks like a hostname → URL: Spoof - userpass looks like a hostname
Flags: blocking1.7b+
Flags: blocking1.7a-
Flags: blocking1.7a+
*** Bug 233467 has been marked as a duplicate of this bug. ***
Flags: blocking1.4.2? → blocking1.4.2-
I have created a patch for the file:
xpfe/browser/resources/content/nsBrowserStatusHandler.js
the onLocationChange function

This is my first Mozilla patch, so please be kind if I've not submitted it
correctly. I wasn't sure how to do a diff so I manually put + signs for the
added lines.

For the username and password to be removed you need to set the following
about:config variable:
browser.urlbar.showUsername	 false

I suggest that variable be set to false by default.
Attachment #143313 - Flags: review?
I talked this over with Darin and we think the better sollution for this is in
bug 232567. The approach taken there is to simply not allow going to a URL that
contains username and password w/o prompting the user about it. That way we let
http:// URL's with username and password continue working, and you can change
them in the URL bar n' all, but spoofers won't be able to direct you to their
site w/o the user knowing.

I haven't followed this bug in detail, but I would suggest that we'd dupe this
against bug 232567.
Bug 232567 looks exactly like my comment 177.  I personally think it's a great
solution, but there wasn't consensus here that it was the best way to go.

Johnny, please do not suggest duping this bug if you haven't read it all. Users
have contributed a lot of time to suggestions and a lot of research on RFCs
which was not done on the bug you mentioned.

Also, my patch solves the problem without displaying a dialog box. Many people
here have stated why a dialog simple won't work.

Where is the flaw in removing the username and password? There can be no
confusion from an end user perspective about what site they are visiting because
now the hostname will be shown where they expect it to be. And this method does
not break any current applications. Your suggestion and the Microsoft
implementation break the Internet as we know it.
(In reply to comment #231)
> Where is the flaw in removing the username and password? There can be no
> confusion from an end user perspective about what site they are visiting because
> now the hostname will be shown where they expect it to be. And this method does
> not break any current applications. Your suggestion and the Microsoft
> implementation break the Internet as we know it.

 (1) many users do not look at the URL bar

 (2) yes, many users just click through alerts, but maybe it'll slow them down
just enough... with an alert we can say:  "are you sure you want to visit
www.evil.com ?"

 (3) striping the username out of the URL bar makes it difficult for users to
edit the username in the URL bar.  "now you see it, now you don't."  suppose you
type the username into the URL, load it, and then want to add something extra to
the end of the URL.  you'd have to go back and re-add the username portion. 
that's a pain.

 (4) if we wait for the user to notice the problem in the URL bar then the evil
site would have already loaded.  by this time it could have done things with JS
to maybe hide the URL bar or cause other mischief.  with the alert based
solution, the user doesn't see the evil site until they dismiss the alert.

i'd hope that from the point of view of a user, the unusual alert dialog would
make them somewhat suspicious.  and maybe that's enough to keep them from doing
something silly.

that said, maybe it makes sense to combine both solutions.  (that is, if we
accept that my point #3 is not significant enough.)
>(1) many users do not look at the URL bar
Many users do not look at dialog boxes. 
For you to even mention that users do not look at the URL bar is silly. The
whole point of spoofing is to trick the user by changing what is in the URL bar.
if they don't look at the url bar then why bother spoofing with a username and
password? You are talking about a COMPLETELY different issue.

>(2) yes, many users just click through alerts, but maybe it'll slow them down
>just enough... with an alert we can say:  "are you sure you want to visit
>www.evil.com ?"
"are you sure you want to visit www.paypal-security-update.com ?"
>but maybe
I don't want to break current implementation for "but maybe". With a dialog if
they click through without reading, then get confused about what just happened
they will look at the url bar and feel reassured because they see:
http://www.paypal.com______________________________:345656@www.evil.com/gotyourmoney.html
Your suggestion could make the issue worse.

>(3) striping the username out of the URL bar makes it difficult for users to
>edit the username in the URL bar.  "now you see it, now you don't."  suppose >you
>type the username into the URL, load it, and then want to add something extra >to
>the end of the URL.  you'd have to go back and re-add the username portion. 
>that's a pain.
goto about:config set 
browser.urlbar.showUsername	 true
problem solved!
users who edit username portions of the url tend to understand how the syntax
works and what the @ symbol means. so showing the username and password for them
is no issue.


>(4) if we wait for the user to notice the problem in the URL bar then the evil
>site would have already loaded.  by this time it could have done things with JS
>to maybe hide the URL bar or cause other mischief.  with the alert based
>solution, the user doesn't see the evil site until they dismiss the alert.
You will have to turn off JS to be safe from what you are describing. Because
that can be done to trick a user when spoofing hasn't occured.


>  (1) many users do not look at the URL bar

See answer to (4)

>  (2) yes, many users just click through alerts, but maybe it'll slow them down
> just enough... with an alert we can say:  "are you sure you want to visit
> www.evil.com ?"

Dialogs are generally considered bad, and I think it's a fairly accepted
hypothesis that users don't read them.

>  (3) striping the username out of the URL bar makes it difficult for users to
> edit the username in the URL bar.  "now you see it, now you don't."  suppose 
> you type the username into the URL, load it, and then want to add something 
> extra to the end of the URL.  you'd have to go back and re-add the username 
> portion. that's a pain.

Would you really? If you just modify/add something to the path-section of the
url then wouldn't mozilla automatically log you in again? Using the
username/password that you're already logged in using.
If I log in to a site (using normal login-procedure, not using username/password
in the url) and then click on a link on that site mozilla won't ask me again for
username and password.

>  (4) if we wait for the user to notice the problem in the URL bar then the 
> evil site would have already loaded.  by this time it could have done things 
> with JS to maybe hide the URL bar or cause other mischief.  with the alert 
> based solution, the user doesn't see the evil site until they dismiss the 
> alert. i'd hope that from the point of view of a user, the unusual alert 
> dialog would make them somewhat suspicious.  and maybe that's enough to keep 
> them from doing something silly.

We should not only modify the code that displays the url in the urlbar. We
should also modify what we are displaying in the statusbar when the user hovers
the link. So if I hover the link "http://foo:bar@evil.com/" we should display
"http://evil.com/ (logging in as username 'foo', password 'bar') in the statusbar.

If users don't look at either statusbar nor url-bar there is nothing we could
do, since the site might just as well link directly to evil.com without any
obfuscation.
What's displayed in the URL bar is what matters, if anything, since spoofing the
status bar is trivial, and no matter what we do they can always override what's
shown on the status bar, as long as our users don't disable setting the status
bar text (which I bet 99% of our users won't do).
(In reply to comment #233)
> The whole point of spoofing is to trick the user by changing what is in the
URL bar.

exactly.  and how do those URLs get in the URL bar?  perhaps from an email
message.  if the user clicks on the URL, then it gets put in the URL bar.  what
motivates the user to look at the URL bar?


> if they don't look at the url bar then why bother spoofing with a username and
> password?

because users click on links.  attackers cannot affect the text in the URL bar
unless the user clicks on a link.

this attack is about (1) tricking users into clicking on a link, and then (2)
tricking users into thinking that they should use the resulting site.

changing the URL bar only helps with (2), but as i've said... once the site
loads, there are more things the attacker can do to try to keep you on the site.
 if we can help users avoid going to evil sites, then we are better off.


> >(2) yes, many users just click through alerts, but maybe it'll slow them down
> >just enough... with an alert we can say:  "are you sure you want to visit
> >www.evil.com ?"
> "are you sure you want to visit www.paypal-security-update.com ?"
> >but maybe
> I don't want to break current implementation for "but maybe". With a dialog if
> they click through without reading, then get confused about what just happened
> they will look at the url bar and feel reassured because they see:
>
http://www.paypal.com______________________________:345656@www.evil.com/gotyourmoney.html

this is why i suggested combining both solutions.


> Your suggestion could make the issue worse.

maybe.


> goto about:config set 
> browser.urlbar.showUsername	 true
> problem solved!
> users who edit username portions of the url tend to understand how the syntax
> works and what the @ symbol means. so showing the username and password for them
> is no issue.

this sounds reasonable to me.


> >(4) if we wait for the user to notice the problem in the URL bar then the evil
> >site would have already loaded.  by this time it could have done things with JS
> >to maybe hide the URL bar or cause other mischief.  with the alert based
> >solution, the user doesn't see the evil site until they dismiss the alert.
> You will have to turn off JS to be safe from what you are describing. Because
> that can be done to trick a user when spoofing hasn't occured.

please explain.  only JS from a page that got loaded can run.  i'm proposing
preventing script from evil pages from ever getting a chance to run.
> Would you really? If you just modify/add something to the path-section of the
> url then wouldn't mozilla automatically log you in again? Using the
> username/password that you're already logged in using.
> If I log in to a site (using normal login-procedure, not using username/password
> in the url) and then click on a link on that site mozilla won't ask me again for
> username and password.

good point sicking.  this makes my point 3 pretty irrelevant.  however, it might
be an issue for FTP.  hmm... switching between anonymous and user login modes.
Re: comment 237
my patch only removes user and pass from http, https
I agree with you that for ftp it's important to keep there, plus there is no ftp
spoofing issue.
I don't see why the same problem doesn't apply to ftp? Nor why the same solution
couldn't be used.
>please explain.  only JS from a page that got loaded can run.  i'm proposing
>preventing script from evil pages from ever getting a chance to run.

you do have a point if people click no on a dialog you suggest they will not be
subject to any trickery from JS.
My main point is that the only JS trick that is affective against my method is
popping a new window and removing the url bar. we have a pop up blocker to
protect users from this. and if user enters sensitive information on a site
which doesnt show the url bar, we would need more than 2 years to figure out how
to "properly" save those people from scames.

I believe we are speaking of 2 different groups of people we are trying to help.
Let me elaborate.

If you do a statistical bell curve. there will be 2 or 3% of people who dont
read the url bar, unsaveable. and I would argue that those that do not read the
url bar, are beyond saving and if you had 10 cents for ever person who reads
dialogs but not the url bar you wouldn't have a dollar.

there will be 2 or 3% of people (like us) who can mentally parse the url syntax.
we don't need help.

then there will be 95% of the people who read the url bar but have no knowledge
of url syntax and get tricked by spoofing because most of the sites they visit
never use a user/pass so they aren't aware that information can be shown in the
url bar. these are the people who will benefit from the fix to this bug.

I think you are not taking human nature into account with your popup idea.
because people dont read them and if they do, people usually want to see what's
behind the hidden door and will click yes anyways. but i do understand that this
is not an issue if there is a combined approach you spoke of.


>because users click on links.  attackers cannot affect the text in the URL bar
>unless the user clicks on a link.

>this attack is about (1) tricking users into clicking on a link, and then (2)
>tricking users into thinking that they should use the resulting site.

>changing the URL bar only helps with (2), but as i've said... once the site
>loads, there are more things the attacker can do to try to keep you on the >site.
> if we can help users avoid going to evil sites, then we are better off.

The easy part of the scam is getting people to click on the link. because most
links dont show the location they show other text "PayPal" as opposed to
http://www.paypal.com 
The harder part is to get people to believe they are at the legitamite site
after they get there (I understand you say dont let them get there, but I think
they will get there, especially if they are worried about having their "account
closed"). Scammers are smart, they even made these fake sites link to the real
sites. For the vast majority of people showing the location without the
username/password will solve the problem. 

The important things in my opinion are this:
1) dialog breaks auto-login systems (may solve this problem, creates another)
2) dialog with removal of user/pass from url, breaks auto-login systems (will
solve problem, still creates another)
3) remove user/pass. it's simpliest solution and will solve the problem, no new
problem created.

this is a numbers game. how many people will get upset from a dialog? many.
how many people will get upset if we remove user/pass? how could they because
they can turn it back on from their end.

end result of my suggestion is problem solved, no websites broken.
end result of a dialog/combo suggestion is problem solved, many websites broken,
many people annoyed.
Re: comment 239

Jonas, as far as I know users cannot enter sensitive information, credit cards
and bank info on an ftp site. ftp sites are for download and upload of files and
do not allow form processing so user cannot be tricked into entering anything
bad on an ftp site.
Put an html-file on an ftp-servet. Let the html-page have a form that posts the
data to an http-server. Direct the user to the html-file while 'spoofing' the
url. Done.
Jonas, can you create a test case for what you are speaking of?
From my knowledge when a user clicks on an html file on an ftp site they will be
prompted to download the file. It will not actually be rendered.

> Jonas, can you create a test case for what you are speaking of?
> From my knowledge when a user clicks on an html file on an ftp site they will be
> prompted to download the file. It will not actually be rendered.

I don't have access to a public ftp-server currently so I can't create a
testcase. But no, we don't do anything different when 'surfing' on ftp vs. http.
jonas is right.  it's no different than loading a HTML file off the local
filesystem.  that HTML file could very well include a form post to a HTTP
server.  so, you serve the HTML file over FTP... the end result is the same. 
the attackers page is loaded into the browser, and from there on it can use a
combination of HTTP and FTP URLs to maintain the elusion.

so, i agree with jonas that we'd want to strip out the username and password for
all URL types.
Darin are you claiming you can render HTML and an HTML form on an ftp server?

if the user has to load HTML from his hard disk, it's not likely he's going to
be fooled by spoofing.

why would anyone enter sensitive information under such circumstances?

if you can indeed show me that you can render an HTML form on an ftp server
(without saving and opening locally), then you have a valid point. Otherwise,
you are out in left field and you don't even understand this issue.

there are other issues that call for removing username and pass from ftp, like
someone "looking over your shoulder", however those are other bugs and other
issues. spoofing definitely has nothing to do with ftp.
You don't "render HTML on an ftp server" any more than you render HTML on an
http server.  You just send the file to the browser, and the browser will render
it, after guessing the content type.  First example I came across:
ftp://www.mirror.ac.uk/pub/Apache/HEADER.html

moreover, mozilla supports pluggable protocol handlers.  that means you could
write a mozilla extension that defines the "x-foobar" URI type.  this URI type
could likewise support download a HTML file (in fact it could work just like
HTTP).  this URI type could also support the concept of login, with the standard
URI syntax for such things.

while it is true that the only other protocol that would be common enough to be
useful by an attacker is FTP, from a code point-of-view it makes no sense to
limit this URL bar patch to HTTP.
I stand corrected and I learned something new. Thanks guys.

Darin, I'll submit a modified patch. Do you suggest I only check for http, https
and ftp or should I not discriminate based on protocol and remove it for all URI?
Peter: you should not discriminate based on protocol.
Peter Kroll,

parse: I see you used string parsing in your patch. I think you should use
nsIURI/nsIURL (using nsIIOService) to parse the URL.

hookup: While looking up to onLocationChange() is a great idea, I'm not sure
that's the right place (statusbar etc.). Compare
<http://bugzilla.mozilla.org/attachment.cgi?id=137693&action=view>.

diffs: You can create diffs using |cvs diff|, assuming you have CVS dirs in the
tree and cvs installed. Otherwise PatchMaker may help. Your file was still
easily readable for humans.
Comment on attachment 143313 [details] [diff] [review]
remove username and password based on boolean preference

patch rejected: Use the nsIURI interface (already available as locationURI) to
manipulate in a standard way -- we've had security bugs due to different bits
of code trying to implement local URI parsing.

getBoolPref() will throw an exception if the pref is not defined -- protect
with a try/catch since there's still more to do whether this fails or not.

I'm not sure this interacts with userTypedValue correctly -- if the user has
typed in this URL it's not a spoof and we shouldn't change it.

I don't think we need a pref to show the real URL. Couldn't a savvy user get
that from the page info screen, and that'd be quicker than changing the pref
and then changing it back to a safe value. If you do add the pref, however,
your patch needs to including adding the default value to all.js to avoid
causing the exception mentioned earlier.

stylistically we prefer to use boolean values directly rather than explicitly
comparing to true/false. "if (!pref.getBoolPref(...))" is fine.

Whatever we decide to do needs to be done for Firefox as well. Is
http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.js the
equivalent spot?
Attachment #143313 - Flags: review? → superreview-
Flags: blocking1.7?
i changed the preference name to browser.urlbar.showUserPass with a default
value of false. in modules/libpref/src/init/all.js
Attached patch using nsIURI instead of local parsing (obsolete) — — Splinter Review 
patch for
xpfe/browser/resources/content/nsBrowserStatusHandler.js

to be used with patch 144499

I have removed the local parsing and used the nsIURI interface. I have added
the appropriate try/catch blocks. I believe I am now correctly interacting with
userTypedValue.
Attachment #144500 - Flags: review?
Flags: blocking1.7? → blocking1.7+
*** Bug 140064 has been marked as a duplicate of this bug. ***
Here's a spoofed URL I received by mail only yesterday (HTML codes simplified):

a
href="http://web.da-us.citibank.com%6Csignin%6Ccitifi%6Cscripts%6C@%69%73%61%70%69%31%30%30%2E%69%6E%66%6F/%69%6E%64%65%78%2E%68%74%6D"
IMG SRC="cid:5BA9EF1D.EF859523.2146CE54.5258F8AC_csseditor" border="0" ALT=""
/a
dependencies the wrong way 'round.
No longer blocks: 157354, 228612
Depends on: 157354, 228612
Attachment #143313 - Attachment is obsolete: true
Comment on attachment 144500 [details] [diff] [review]
using nsIURI instead of local parsing

see patch in bug 157354 instead
Attachment #144500 - Flags: review? → review-
Comment on attachment 144500 [details] [diff] [review]
using nsIURI instead of local parsing

see patch in bug 157354 instead
Attachment #144500 - Attachment is obsolete: true
*** Bug 228521 has been marked as a duplicate of this bug. ***
Depends on: 232567, 240754
Flags: blocking1.7a-
Flags: blocking1.6-
Flags: blocking1.4.2-
Flags: blocking1.7+ → blocking1.7-
Just grabbed Firefox 0.9RC1.  And I must say... I REALLY hate the way this was
handled in FireFox.  Not one but TWO dialog box pop-ups every time you have a
URL with an embeded user/pass. 

I just hope Mozilla didn't do the same thing.
Mozilla does, but it was just fixed. bug 246106
*** Bug 249034 has been marked as a duplicate of this bug. ***
i read about this bug through the 1.8a2 release readme
i think their is a way

that mozilla can avoid it their has to be ":" in the text before the @
then if their wasn't then matbe it would report it as invalid url
Certainly a lot of comments have been passed around. 
But as a user I prefer to rest assured that the URL I am visiting is from the
site I am expecting.

A simple way to do this is as proposed with a new style of displaying host site
(You would know which server you are contacting) and any extra security
information available.

There has been debate over screen real estate but I have noticed a lot of screen
real estate on the status bar. I am sure this can be incorporated there.

As a user I am frightened that some well crafted email can dupe people into
thinking they are visiting a trusted site.
KS: See bug 245406.

Gerv
Aviary is temporarily regressing a fix/workaround which made part of this
problem less of a problem (bug 252811) by landing the fix for bug 22183, so we
will need a solution to this problem for the 1.0 release. Setting flag to
blocking 1.0 to make sure we don't drop this one.
Flags: blocking1.7b+ → blocking-aviary1.0+
I think this is the bug responsible for the "You are about to log on to the site
$x with a username of $y" warning in Firefox 0.10. Minor issue with it: if you
click No to this dialog, the favicon is loaded and put in the current tab
anyway. I guess there's not really any security issue with that, but it's pretty
bad form.

Also, shouldn't there be a checkbox to disable this warning in the future
(defaulting to "continue to show" of course), for people who actually know how
to read a URL? I should think some intranets make use of user@host links for
legitimate purposes.
jmd: Please file new bugs in, well, new bugs. Thanks!
> jmd: Please file new bugs in, well, new bugs. Thanks!

Well, the status whiteboard DOES say to comment about the patch! Anyway, filed:
  bug 260988 - favicon loading issue
  bug 260989 - add a checkbox to disable warning pop-up
Flags: blocking1.7-
This does not block... dveditz fixed this in docshell independently of any
aviary UI.
Flags: blocking-aviary1.0+
A couple of newer bugs that describe similar vulnerabilities:

Bug 275417 - Download dialog source spoofing
Bug 258601 - downloading a long file name will not display the full file name

As for this bug, it seems to be fixed in both Seamonkey and Firefox. Is there
any reason to keep it open?

Prog.
No longer blocks: majorbugs
This bug should be closed?  Seems nicely fixed to me.
So, is this bug fixed, or isn't it? I didn't dare clicking the link in comment #2 to see what actually happened.
at least in firefox 3, url in comment #2 it shows a warning that is trying to open a connection to hardware.no when you might think that its going to www.microsoft.com

so yes, i think it could be called as fixed
Since I don't know where it was "fixed", I'm tentatively marking this bug WORKSFORME.

Notes for anyone visiting this bug:

- If it doesn't work for you on a "trunk" version (at the moment Firefox 3 or SeaMonkey 2), please REOPEN and paste your user-agent string in your comment, that string can be found on the about: page and looks more or less like this:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041201 SeaMonkey/2.0a1pre

- If it doesn't work for you on Firefox 2 or SeaMonkey 1.1.x, _don't_ reopen but paste your user-agent as above and add [needs fixing 1.8] in the "Whiteboard" field at top (FIXED means "fixed on trunk").

- If it doesn't work for you on Firefox 1.5.x or earlier, on SeaMonkey 1.0.x or earlier, or in the Mozilla Suite, the only solution is to upgrade to a newer model, because these aren't supported anymore.
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: helpwanted
Resolution: --- → WORKSFORME
Whiteboard: spoof [comment only about the patch implementation]
See comment 260 from Daniel Veditz:
> (From update of attachment 144500 [details] [diff] [review])
> see patch in bug 157354 instead

So, this was fixed, and the patch attached here originally, the patch was just checked in in another bug and Dan forgot to mark this one FIXED.
Resolution: WORKSFORME → FIXED
(or a different patch to fix this was used)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: