32761 - URL: Passing user id and null password via HTTP ("user:<NULL>")

Status: NEW

(Core :: Networking, defect, P5)

Description

[yoel]

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en]C-DIAL  (WinNT; U)
BuildID:    2000022820

Mozilla does not respect a null password in a URL, i.e. when there is no space 
between the colon and @ sign. This RFC states that if a colon exists then a 
password is being supplied.
Here is the RFC that discusses this format. 
ftp://ftp.isi.edu/in-notes/rfc1738.txt

In the 4.0x Communicator code when a user passed a null password in a url the 
userid and password were sent to the server.
http://user:password@host

In 4.5+ this was changed and Communicator no longer sent the URL to the server, 
but prompted the user for the password.
This is going to be fixed, see 388773 (Netscape Only) 

Reproducible: Always
Steps to Reproduce:
1.setup a server with a user db that allows null passwords, I think MS SQL and 
Access allow this
2. Type in a URL to that server including the userid and null password
http://user:@host


Actual Results:  An HTTP Authentication dialog was presented to me

Expected Results:  I should be able to acces the site

Comment 1

[Greg Breland]

This bug should be marked VERIFIED, but I don't have permissions.

I tested this against my web site with NB 20000412.  I used a URL like
http://test:@www.site.com  and was shown a username/password dialog instead of
being let into the site.  I could not verify that other browsers would work
because Netscape 4.72 also will not allow NULL passwords to be passed.

BTW, I could not login with a NULL password either via embeding it in the URL
nor by using the username/password dialog in either 20000412 or NN 4.72.

Comment 2

[yoel]

This will be fixed in an upcoming release of 4.x.

Comment 3

[Gervase Markham [:gerv]]

Greg Breland - are you saying this bug is fixed, or that you can definitely see 
it?

Gerv

Comment 4

[Andreas Otte]

I can confirm this is happening on mozilla with ftp accounts. Something like
ftp://user:@host/ will present you the box to type in the password, but the
empty password is not accepted. You can not log into such an account, which is
not so bad, since it forces people to put passwords on it. ;)

Comment 5

[Gagan]

Hmmm... I don't think we check for empty passwords inside necko. Seems like 
wallet problem. over to morse for investigation. 

Comment 6

[Stephen P. Morse]

It's not a single-signon problem.  I'm just the messenger here -- if you 
called me to put up a dialog, then that's what I do (unless of course I 
already find an entry in my saved-password database).  If you didn't want a 
password dialog, then you shouldn't have called me.

I don't do any parsing of the url string to determine if it contains a username 
and/or password.  I used to parse the username out of the url but warren felt 
that was the wrong thing to do and he removed all the parsing code from single 
singon.

Comment 7

[Andreas Otte]

Forget my last comment about ftp on this problem. Non-anonymous ftp access needs
a password by definition, there are no private ftp accounts without password. 

Comment 8

[Andreas Otte]

Maybe the problem here is that we can not tell the difference between no
password (null) and empty password ("") when this is stored in an AutoString or
something similar.

Comment 9

[Gagan]

nsbeta3- becuz of lesser visibility

Comment 10

[Darin Fisher]

->me

Comment 11

[Darin Fisher]

removing stale nsbeta3 keyword.

Comment 12

[Alexey Chernyak]

RFC1738 is long outdated
The latest is RFC2396
The format it uses is <userinfo>@<host>:<port> and not <user>:<pass>@<host>:<port>

So maybe you should try not to put the : before @ and see what happens.

Comment 13

[benc]

Alex, I think the point is this:

   Note that an empty user name or password is different than no user
   name or password; there is no way to specify a password without
   specifying a user name. E.g., <URL:ftp://@host.com/> has an empty
   user name and no password, <URL:ftp://host.com/> has no user name,
   while <URL:ftp://foo:@host.com/> has a user name of "foo" and an
   empty password.

This is valid even in the newer RFC:

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

"username:" would be a valid userinfo.

re: andreas' comment, I recall (but did not check today) that ftp servers do not
all require passwords, some require only usernames.

Comment 14

[Darin Fisher]

does this bug still exist with moz 1.4 alpha?

Comment 15

[Andrew Hagen]

No response in over a year. 

Resolving WFM.

Comment 16

[benc]

I missed darin's comment.
This still happens in 1.6f.

Comment 18

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

RFC 3986 is the current spec:

   userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )

   Use of the format "user:password" in the userinfo field is
   deprecated.   Applications should not render as clear text any data
   after the first colon (":") character found within a userinfo
   subcomponent unless the data after the colon is the empty string
   (indicating no password).

So this usage is entirely deprecated except for the case here, a null password.