Last Comment Bug 34943 - Domain guessing (automatic www. and .com) shouldn't happen on links/URLs
: Domain guessing (automatic www. and .com) shouldn't happen on links/URLs
[ADT2 RTM] security
: topembed+
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: P3 normal with 1 vote (vote)
: mozilla1.0
Assigned To: Adam Lock
: benc
: 31335 65421 133056 (view as bug list)
Depends on: 60768 115539
Blocks: 37867 63736 68407 104166 143047
  Show dependency treegraph
Reported: 2000-04-06 18:51 PDT by Jesse Ruderman
Modified: 2014-04-26 03:32 PDT (History)
17 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (2.55 KB, patch)
2002-02-21 07:06 PST, Adam Lock
brade: review+
mscott: superreview+
asa: approval+
Details | Diff | Review
Pref diff (796 bytes, patch)
2002-03-21 10:38 PST, Adam Lock
no flags Details | Diff | Review
Patch disables fixup on link click (648 bytes, patch)
2002-03-25 11:08 PST, Adam Lock
no flags Details | Diff | Review
Test case (371 bytes, text/html)
2002-03-25 13:12 PST, Adam Lock
no flags Details
Updated patch to disable fixup on link click (1.05 KB, patch)
2002-03-25 13:33 PST, Adam Lock
radha: review+
rpotts: superreview+
asa: approval+
Details | Diff | Review

Description Jesse Ruderman 2000-04-06 18:51:09 PDT
Mozilla should only add the automatic "www." and ".com" to urls when the user
types the URL in, not when the user clicks a link such as http://mozilla/ .

This is a potential security issue: suppose you have a computer named chameleon
on your network and log into it through the web using http://chameleon/* .
Someone manages to DoS chameleon and also gets ahold of the domain
name.  Next time you try to log into chameleon using your local copy of the
login form, they get your password.  Then they go to and log in using your password (unless chameleon
is selective in which IPs it allows to log in).
Comment 1 Sean Richardson 2000-04-07 00:07:00 PDT
Problem confirmed with 2000-04-06-10-M15 on WinNT.

Adding to Cc: list -- this does look like a security
issue to me as well, and one that would not necessarily need so complicated
a scenario to be problematic.

While nobody else could reproduce the problem, bug 17657 reports a problem
where only the "www." ".com" version was ever visited.
Comment 2 Gagan 2000-04-07 02:37:59 PDT
good catch. ->travis
Comment 3 travis 2000-04-17 00:34:51 PDT
Should be fixed now...
Comment 4 Jesse Ruderman 2000-04-22 09:26:16 PDT
2000 042112, and still happens.  Reopening.
Comment 5 John Morrison 2000-05-24 16:25:17 PDT
This works correctly with 20000524 win32/linux/mac builds. Clicking on a 
link (e.g., http://blues/ ) takes the browser to the local domain host 'blues'.
Putting back fixed.
Comment 6 Jesse Ruderman 2000-06-10 11:15:56 PDT
reopening (build 2000 060820 win98)

http://mozilla/ takes me to .
http://blues/ takes me to, which redirects to another 
Comment 7 Judson Valeski 2000-06-27 09:43:33 PDT
-> jud
Comment 8 Jesse Ruderman 2000-09-09 13:54:59 PDT
Similarly, a link to should fail but the same URL typed into 
the location bar should work.
Comment 9 Jesse Ruderman 2000-09-25 18:26:04 PDT
And another one: file:///foo/bar/ -> file://///foo/bar/ , which is making bug 
38643 (a win9x crasher) happen more often than it would otherwise.
Comment 10 Jesse Ruderman 2000-09-30 23:04:44 PDT (from bug 31854) probably shouldn't work as a link.
Comment 11 Adam Lock 2000-11-27 11:10:56 PST
Adding a dependency on bug 60768 which deals with moving the fixup code into a 
separate service.
Comment 12 Jesse Ruderman 2001-01-14 17:50:36 PST
Ccing mstoltz and nominating for nsbeta1.

Bug 65421 might be a dup.
Comment 13 Mitchell Stoltz (not reading bugmail) 2001-01-16 12:24:05 PST
Comment 14 Mitchell Stoltz (not reading bugmail) 2001-02-02 15:54:27 PST
Jesse's attack scenario is a bit implausible - an attacker would need to a) know
the name of a machine on your intranet that might contain interesting
information, and b) own the equivalent domain name in .com. Can anyone come up
with a more plausible scenario?

Maybe we should have a pref for "assume www.*.com" or "never assume." 
Comment 15 Jesse Ruderman 2001-02-03 01:00:45 PST
Ok, maybe it's not that big of a security hole.  It's still a bug though.

I don't think a pref is needed: this type of URL correction should never happen 
on links (or form submission, or going to a bookmark), and if you type the URL 
into the location bar you're likely to notice when it changes.
Comment 16 Jesse Ruderman 2001-02-08 16:03:43 PST
The W3C thinks there *should* be a pref for turning off www. / .com guessing 
for URLs typed into the location bar (I said in my previous comment that I 
didn't think a pref would be necessary).
1.6 Allow the user to override any mechanism for guessing URIs or keywords. 
Many user agents compensate for incomplete URIs by applying a series of 
transformations with the hope of creating a URI that works. For example, many 
user agents transform the string into the URI 
The user should be able to control whether, for example, typing a keyword 
should invoke a Web search or whether the user agent should prepend http://www. 
and append .org/.
Comment 17 Jesse Ruderman 2001-02-10 13:45:41 PST
The W3C CUAP's suggestion of having a pref to always turn url-fixing off is now 
bug 68407.
Comment 18 Moses Lei 2001-02-11 08:25:31 PST
bug 65421 should be added to the list of bugs that this blocks.

I saw this when I clicked a link to "http://primates/~vladimir" on slashdot.
Someone from ximian had erroneously posted an internal URL. When I clicked the
link, I got to a netscape search on "primates." I thought this was someone's
idea of a practical joke, but when I looked back at the link, I found it was
this bug...

FYI I have internet keywords turned on.
Comment 19 Marcello Nuccio 2001-03-12 10:39:57 PST
A link like http:/cgi-bin/man2html?locate+1l (note the single '/' after 'http:')
should be interpreted as relative to the hostname in the URL of the page.

Example: I'm reading
and I click on the link above; Navigator4.76, lynx and w3m load
Mozilla (Build ID: 2001031005; Linux) loads
if internet keywords are disabled, and
if internet key are enabled.

With this bug, man2html it's unusable with Mozilla, because it generates only
reltive links!
Comment 20 Andreas Otte 2001-03-15 12:11:43 PST
This kind of relative urls is deprecated with rfc2396 and we decided to no
longer support it. 
Comment 21 Robert Kaiser (not working on stability any more) 2001-04-17 07:54:36 PDT
Marcello, Andreas, isn't that what bug 65421 is exactly about?
Comment 22 benc 2001-05-21 16:10:41 PDT
Open Networking bugs, qa=tever -> qa to me.
Comment 23 benc 2001-05-22 01:36:47 PDT
re: Michael

Its a security hole for two reasons:

1- Even if a domain is not actively using a web server @ www.<hostname>.com, a
wildcard DNS record could be used to send all web requests somewhere.

2- Anytime this goes out some place to the wrong machine, it could carry
information in the URL to a remote site. (This is the same reason I object to
the internet kewords feature being hooked up as a secondary handler between
hostname resolution and posting DNS errors...)
Comment 24 Mitchell Stoltz (not reading bugmail) 2001-05-22 13:11:13 PDT
Good points, Ben. Necko-level security needs a serious look in general.

If your last comment was directed at me, the name is Mitchell, not Michael.
Comment 25 benc 2001-05-22 18:03:27 PDT
sorry. too many bugs, not enough sleep...
Comment 26 basic 2001-06-15 19:56:30 PDT
As of build 2001061404 win32 installer sea trunk
this seems to be fixed except that Mozilla doesn't give any error messages for
invalid links.
Comment 27 benc 2001-06-21 14:19:06 PDT
Since DNS cache is not going to support negative entries, fixing this would do a
lot for overall DNS performance in real-world situations.

There is also and RFE for even more liberalized hostname -> Top Level Domain
searching (bug 37867), and I think that would worsen the problem further, so I'm
blocking that bug with this bug.
Comment 28 Ben Bucksch (:BenB) 2001-06-21 18:10:33 PDT
> Jesse's attack scenario is a bit implausible - an attacker would need to a)
> know the name of a machine on your intranet that might contain interesting
> information, and b) own the equivalent domain name in .com. Can anyone come up
> with a more plausible scenario?

Given that many "words" under .com are already registered and hooked up, it is
not unlikely that there will be a corresponding <> for your
internal <http://jazz/>. So, if you try to log into an internal server and it
happens to be down, your login information might leak into the public internet
to a "random" site. Such a case could appear accidently, without any "attacker",
nevertheless confidental information has been revealed.

Note: I am behind a Squid proxy and I don't see this bug with 0.9.1.
Comment 29 benc 2001-09-19 11:19:47 PDT
reseting owner to defaul
Comment 30 Jonas Jørgensen 2001-12-16 12:23:34 PST
Why does Mozilla try to add "www."? Why does it need to? Wouldn't the easiest
way to fix this simply be to disable the www-adding?

Personally I find the automatic www-thing very annoying. If a machine in a local
network called 'whatever' is down, why would I want Mozilla to try It's a waste of bandwith, and almost all important sites work
without www. anyway.
Comment 31 Morten Nilsen 2001-12-31 16:25:45 PST
*** Bug 115539 has been marked as a duplicate of this bug. ***
Comment 32 Jonas Jørgensen 2002-01-01 09:43:14 PST
Will fixing bug 115539 also fix this?
Comment 33 Ben Bucksch (:BenB) 2002-01-01 10:55:04 PST
Comment 34 Jonas Jørgensen 2002-01-05 15:02:22 PST
Marking dependent on bug 115539.
Comment 35 Henrik Gemal 2002-01-14 13:36:58 PST
auto adding www. or .com is plain weird. Btw we're not all in a .com world. What
about .org, .net, .dk, .info... etc
Comment 36 neeti 2002-02-20 13:02:29 PST
related to 115539
Comment 37 Adam Lock 2002-02-20 14:29:42 PST
*** Bug 115539 has been marked as a duplicate of this bug. ***
Comment 38 Adam Lock 2002-02-20 14:32:33 PST
The www. & .com appending should be a pref but I don't see it as a security issue. 

The code in nsDefaultURIFixup::MakeAlternateURI doesn't do anything if the URL
contains user or password information.
Comment 39 Cesar Eduardo Barros 2002-02-20 14:51:53 PST
Uh, not a security issue? => -- ok it's just Debian but it could be
something you don't want people to know

internalserver => -- this one should never leave the
internal network, but instead it goes straight to the external DNS servers. With
a bit of luck (hah), is owned by someone you don't like. And
now they know an URL within your internal network.

I'm sure more creative people could think of even better examples. Look up the
jargon file entry for DWIM to see why guessing and acting on behalf of the user
based on that guessing is Evil and Rude.
Comment 40 Matthew Hannigan 2002-02-20 16:54:54 PST
Security: also consider the typo www.creditcardcom (missing dot)
Mozilla will expand this to  Now imagine
if this exists and is a lookalike for the creditcard site.
You could easily give it personal information before you
noticed. Badness.

Lest this seems far fetched I know for a fact that at least one
famous site has a framing and linking copycat site which does exactly
this.   See my comments for bug 125871.

To me, this means that mozilla should NEVER mangle a url, whether
typed in or from a clicked link.  Cesar's comments about DWIM are
spot on.
Comment 41 Mitchell Stoltz (not reading bugmail) 2002-02-20 17:12:23 PST
I do see this as a security issue (spoofing), and we can argue as to the
severity, and risk vs. the inconvenience of removing this feature that people
ahve come to expect. The URL bar is generally permissive of a wide range of
input errors. Any thoughts on the security/functionality tradeoff here?
Comment 42 Cesar Eduardo Barros 2002-02-20 17:30:11 PST
The only thing I've come to expect is the automatic prepending of http:// .
That's a huge time saver. I believe lots of people here agree with me.

Adding www. and .com only sometimes (depending on the particular relative
timings of the DNS servers, the resolver timeout, and the phase of the moon)
violates the principle of least susprise. Like when I (on lynx) tried to load
"" and got a default Debian Apache page -- only to find out
after chatting with the Debian developers that it had misautoguessed something
like "". Which some kind soul set up to point to I was seeing a page on my own box -- something I would not expect.

Of course, now I have disabled it on lynx.cfg...
Comment 43 Mitchell Stoltz (not reading bugmail) 2002-02-20 17:38:54 PST
I'm convinced. There have been several dupes showing porn sites which take
advantage of this. I'm for fixing this, but I will try to get some more opinions
around here.
Comment 44 Adam Lock 2002-02-21 05:47:04 PST
To clarify the current behaviour:

if there are no dots in the name (e.g. foo)
else if there is one dot in the name
  if it starts with www. (e.g.
  else (e.g.
  do nothing

So should become (assuming doesn't exist)

I can add a pref e.g. "fixup.alternate" plus prefs for the strings to stick on
the front and the back.
Comment 45 Ben Bucksch (:BenB) 2002-02-21 06:38:49 PST
Just get rid of it.
Comment 46 Adam Lock 2002-02-21 07:06:58 PST
Created attachment 70713 [details] [diff] [review]

Patch makes fixup configurable via prefs. The UI for this & default prefs can
be determined in another patch.
Comment 47 Kyle Krom 2002-02-21 12:12:28 PST
If bug 115539 is going to remain a duplicate of this one, then this bug's
summary should be updated to include typed URLs, in addition to links.
Otherwise, 115539 should remain a separate bug.
Comment 48 Kathleen Brade 2002-02-22 11:49:06 PST
Comment on attachment 70713 [details] [diff] [review]

Comment 49 benc 2002-03-04 04:53:59 PST
+nsbeta1 - I'm dogfooding on this bug now.

#47 - I've separated the two bugs by reopening the dupe...

I've modified the summary to make more sense, and use the term "domain guessing"
for this behavior that seems to have no name...

Location is user input, which is a legitimate area for some type of shortcut and
domain guessing behavior (w/ a dozen or so good bugs filed against it).

We don't do this for https: apparently (a from the patch's code snippet says:)

 // Code only works for http. Not for any other protocol including https!

Domain guessing in links is really bad because you don't know what the author's
intent was. I just spent all night sending requests to www.<SERVER>.com, because
I clicked on links that had hostnames. This revealed a bunch of URI's to whoever
is running those systems. The authors will go unnamed, but they should be very
glad they didn't have URL's like "http://server/project/januaryshipdates.html".

I think it is important to understand what the level of confusion involved here.
I understand that this person understands their system is named "system", so
they make links like "http://system/" and think their work is done.

However, this person has already ignored several messages from me to literalize
just what he mean to point to with his links, I think this is reasonable proof
that another netscape employee should fix this problem for that person's sake.

Also, you get situations like an email message that actually had a link that
said: "my server is HERE" (with as the HREF), but then
also puts at the bottom of the message "" (with the HREF
of http://server/) !!!

Fixing this would easily minimize the security leaks some publishers inflict
upon themselves, as well as save users the frustration of staring at the
throbber as DNS tries to find something that matches one of the incorrect guesses.

4xp does this, but I think we should override the legacy behavior for better

Expanding localhost is another example of where we have problems.

The only form of hostname -> expanded domain I think is reasonable is bug 88217,
because that actually reflects a user's attempt to make these things go away.

Also, the debian examples might be partially explained by bug 40082, which
depends on bug 124565.

Comment 50 Scott MacGregor 2002-03-06 22:47:56 PST
Adam, I didn't fully scan through benc's comments but if I'm reading it
correctly it sounds like he has some concerns with the behavior with this patch.
Is that right, if so can you address those? If not, email me again for a super
review and I'll take a look at the patch.  
Comment 51 Jonas Jørgensen 2002-03-19 12:43:59 PST
Uhm, what's holding back the patch?
Comment 52 Adam Lock 2002-03-20 12:28:10 PST
I'll resubmit the patch for sr. I know it doesn't address all the issues raised
by this bug so I won't close the bug. But the patch will allow people to disable
the feature entirely if they want for time being.
Comment 53 Scott MacGregor 2002-03-20 12:40:36 PST
Comment on attachment 70713 [details] [diff] [review]

Do we already have default pref values for: 

If not, can we add defaults?

everything else looks good. sr=mscott
Comment 54 Adam Lock 2002-03-21 10:38:28 PST
Created attachment 75410 [details] [diff] [review]
Pref diff

Changes to all.js to add defaults for these prefs.
Comment 55 Asa Dotzler [:asa] 2002-03-21 13:02:01 PST
Comment on attachment 70713 [details] [diff] [review]

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Comment 56 Jonas Jørgensen 2002-03-22 02:16:12 PST
> +pref("browser.fixup.alternate.enabled", true);

Shouldn't this be

  +pref("browser.fixup.alternate.enabled", false);

Comment 57 Adam Lock 2002-03-22 12:00:53 PST
First patch is checked in. The prefs mean the behaviour is the same as before
but at least you can disable it now.

Next patch will address how best to do fixup such that URIs in the address bar
are fixed up if loading fails but no link clicks.
Comment 58 Jonas Jørgensen 2002-03-23 06:55:07 PST
> The prefs mean the behaviour is the same as before
> but at least you can disable it now.

That's what the prefs mean, yes, but why do you want it to be enabled by
default? I strongly believe this should default to disabled, at the very least
until bug 66183 is fixed.
Comment 59 Matthew Hannigan 2002-03-23 19:58:17 PST
I also strongly agree that the default should be off.
Read the above comments especially those mentioning security concerns.

It's also hard to see where this "feature" would help anyone these days,
with the proliferation of non .com urls.  It's more likely to baffle
than help, especially relative internet newbies.
Comment 60 Gervase Markham [:gerv] 2002-03-24 10:16:55 PST
Someone file a new bug and provide the relevant one-line patch to have it turned
off by default. Then, we can have the debate.

Comment 61 Gervase Markham [:gerv] 2002-03-24 10:18:09 PST
Oops... this is still open. Still, I think a new bug might be better. One bug,
one issue.

Comment 62 Jonas Jørgensen 2002-03-24 10:37:28 PST
I've reopened bug 115539 to debate whether browser.fixup.alternate.enabled
should be true or false by default.
Comment 63 Adam Lock 2002-03-25 11:08:30 PST
Created attachment 76004 [details] [diff] [review]
Patch disables fixup on link click

Fix turns out to be straightforward - only do fixup for LOAD_NORMAL loadtypes.
Don't do fixup for any other type, e.g. LOAD_LINK.

Reviews please.
Comment 64 Ben Bucksch (:BenB) 2002-03-25 11:16:27 PST
I did a quick LXR search
<> and it seems that
LODA_NORMAL is used in other cases than the urlbar, i.e. for image loading. It
should only *ever* happen in the urlbar, everything else is a bug (possibly
Comment 65 Adam Lock 2002-03-25 11:24:45 PST
The LOAD_NORMAL I'm testing for is a docshell flag. Are you sure you're not
confusing it with nsIRequest::LOAD_NORMAL?
Comment 66 Ben Bucksch (:BenB) 2002-03-25 12:11:48 PST
No, I'm not sure.
Comment 67 Adam Lock 2002-03-25 13:09:54 PST
LOAD_NORMAL is a combination of flags for the docshell and has nothing to do
with the LOAD_NORMAL flag on the nsIRequest interface.

By adding this test I am able to restrict URI fixup to normal docshell load on a
document which means fixup will not happen on pages loaded from cache, from
history, from a link click and various other combinations. Inline content such
as images, css, iframes etc should not be fixed up either.

I will attach a testcase to demonstrate.
Comment 68 Adam Lock 2002-03-25 13:12:52 PST
Created attachment 76054 [details]
Test case

Some HTML with some duff links that shouldn't be fixed once the patch is
Comment 69 Adam Lock 2002-03-25 13:33:21 PST
Created attachment 76059 [details] [diff] [review]
Updated patch to disable fixup on link click

Updated patch handles frames & iframes too
Comment 70 benc 2002-03-26 19:23:25 PST
qa to me.
Comment 71 Radha on family leave (not reading bugmail) 2002-03-28 12:42:53 PST
r=radha (after conferring with Adam)
Comment 72 Alfonso Martinez 2002-03-31 03:54:56 PST
*** Bug 133056 has been marked as a duplicate of this bug. ***
Comment 73 rpotts (gone) 2002-04-01 12:25:26 PST
Comment on attachment 76059 [details] [diff] [review]
Updated patch to disable fixup on link click
Comment 74 Asa Dotzler [:asa] 2002-04-01 18:28:23 PST
Comment on attachment 76059 [details] [diff] [review]
Updated patch to disable fixup on link click

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Comment 75 Adam Lock 2002-04-02 06:22:33 PST
Requesting adt1.0.0+.

Risk summary - low. Patch is self contained and reasonably obvious. It
suppresses www. & .com fixup for link clicks & subframes. 
Comment 76 Jaime Rodriguez, Jr. 2002-04-02 17:00:17 PST
adt1.0.0+ (on ADT's behalf) for checkin into 1.0.
Comment 77 Adam Lock 2002-04-03 03:37:37 PST
Fix is checked in.
Comment 78 benc 2002-04-11 20:12:56 PDT
The idea test for this would check every URL entry point, the full list of which
I do not have in my head.

Does anyone have the HTML expertise to tell me if there are additional tags
besides  what is covered in the testcase?

Comment 79 Jesse Ruderman 2002-04-11 21:54:48 PDT
benc: for a list of URL entry points (?) that often misbehave, skim bug 55237
and bug 69070 (at least bug 55237 comment 0 and bug 69070 comment 24).  I'd also
test frames, iframes, "view image" (context menu), "save link target as", and
"open link in new window".  If you're bored, test all of those for referrer and
checkloaduri as well :)
Comment 80 benc 2002-04-12 14:57:00 PDT
Linux 2002-04-09-08
MacOSX 2002-04-10-08
Win32 200-04-09-03

jruderman: yikes. that's a lot of stuff. I took QA of the Domain guessing bug
because they are related to DNS.

I'm not going to (at this time) hunt around all the places people call Necko for
URLs and figure this out. I should note that Open Tab and Open New Window seem
to have inconsistent DNS error handling/Domain Guessing behaviors as well.
Comment 81 Jaime Rodriguez, Jr. 2002-05-27 16:43:07 PDT
Was this fixed on the 1.0 branch? If yes, then pls mark this bug as fixed1.0.0,
so QA can verify the fix.
Comment 82 benc 2002-06-05 08:37:39 PDT
This looks like it was fixed pre-branch, based on my comments. However, at least
one person has reported a regression: bug 147119.
Comment 83 timeless 2002-07-22 21:02:49 PDT
*** Bug 65421 has been marked as a duplicate of this bug. ***
Comment 84 2002-08-24 09:19:35 PDT
As in comment #5
Try this:
click on this link http://blues/ then middle-click on the link again.
If you midle-click, the host blues is tryied, and then is tryied.
I don't know if the midle-click issue goes in this bug too.
It seems that the midle-click ends up here:

I have setup the midle-click to open the link in a new tab in the background.

Used: Mozilla 1.0.1 RC1 on WinXP
Comment 85 Jesse Ruderman 2002-10-25 13:20:23 PDT
Oliver: see bug 159742, "URI fixup happens after 'open link in new window' as if
the address was typed by hand".
Comment 86 2002-10-29 09:09:44 PST
Thanks Jesse,
I'm going to bug #159742 since this bug is closed.
Comment 87 benc 2003-04-02 08:08:17 PST
*** Bug 31335 has been marked as a duplicate of this bug. ***
Comment 88 Stefan 2011-07-11 11:45:46 PDT
Why is the status of this bug "VERIFIED FIXED"? The issue is alive and Bug 159742 is still "NEW".

Note You need to log in before you can comment on or make changes to this bug.