Closed Bug 110705 Opened 23 years ago Closed 22 years ago

basic auth no longer being automatically presented

Categories

(Core :: Networking: HTTP, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: anthony, Assigned: darin.moz)

References

Details

Some time between 2001-11-11-09 and 2001-11-18-06, something got
busted with basic auth so that once you've logged in, Mozilla no
longer automatically presents the WWW-Authenticate header with
each request, but instead waits to get a 401, then sends the request. 
This has busted Zope's web management interface completely. I'm going to
try and figure out exactly when this happened...
Status: UNCONFIRMED → NEW
Depends on: 96121
Ever confirmed: true
I am seeing this too, on 20011221 (newer builds for solaris seem to be slow in
coming...)

I'd confirm if I could :-)
I am no longer seeing this in 2002011410, according to my sniffer, but I'm wary
of saying "works for me".

IIRC, this problem would not manifest itself reliably.  It seemed that it would
come and go several months ago.

Reporter: are you seeing this with more recent builds?
This is NOT fixed.  I can't figure out what triggers the bad behavior, but it
still exists in 2002011410.
keeping this untargeted until we have a reliable testcase.
You wanna testcase?  I got your testcase, right here. :-)  (Build ID: 2002013003
on Win32.)

You need:

1.  Zope 2.4.3 from http://www.zope.org/Products/Zope/2.4.3 (any of the binary
or source dists should do)
2.  ftp://ftp.zigg.com/pub/Data.fs.gz -- gzip -d and put into Zope's var
directory before starting Zope.  (If it's OK to attach 650k files, please either
let me know or do so...)

This will give you a minimalist Zope install where the Manager username and
password are both 'admin'.  Start it (on Windows, execute 'start.bat', on UNIX,
run the 'start' shell script.).

To see the bug in action, log in to the Zope management interface (ZMI) with the
URL http://hostname:8080/manage/ (the trailing slash is important!) and the
'admin' username and password, and select 'Simple ZClass' from the Add list in
the lower-right frame.  Enter an id (I used 'Test'), and click 'Add'.  Now
you'll get the error you see in http://collector.zope.org/Zope/121; the reason
you're seeing this is because Mozilla is making the request _without_ an auth
header.  If Zope returned a 401 instead of a 503 (arguably a Zope bug that it
does return a 503), Mozilla would send the request again automatically with the
auth header.

Now, if you were to close Mozilla and repeat the same experiment, logging on
with the URL http://hostname:8080/manage, Mozilla would _not_ fail to send the
auth header, and therefore you'd be able to succesfully create the instance of
the Simple ZClass.

I hope this is sufficient.  Anyone needing help with Zope please let me know...
I have another more comments, and wanted to pass on the results of a little
legwork I did wrt standards behavior and authentication.  Maybe some of this is
a little premature -- this may indeed be just a bug -- but I think it's
warranted discussion.

1.  Zope passing a 503 instead of a 401: this is indeed clearly a bug in Zope,
which is why I also filed the bug in Zope's collector.  However, it is also
important to realize that in systems like Zope, it is 100% correct behavior for
an action to have different consequences based on whether the user is
authenticated or not.

2.  The Mozilla behavior of treating manage and manage/ differently may have its
roots in this bit from RFC 2617:

   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge.

This seems to say that we *should* indeed be treating manage/ differently (as a
folder, whereas it would seem that 'manage' is a non-folder object), even though
Zope's publisher knows it's really the 'manage' object -- the request that fails
does not begin with manage/.  However, one must then ask whether or not it's
correct to *ever* send the authorization automatically, even when challenged,
outside of what we believe is the folder.

Immediately following that paragraph we have:

   A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.

which seems to indicate that the automatic sending of authorization headers
should depend on this protection space.

It is interesting to note that the concept of "this level or deeper" originated
in HTTP/1.1.  HTTP/1.0 (RFC 1945) does not mention this; instead it defines the
protection space thusly:

   The realm value
   (case-sensitive), in combination with the canonical root URL of the
   server being accessed, defines the protection space.

RFC 2617 actually carries this definition forward, so it seems to me that RFC
2617 is in conflict with itself.

To wrap all this up, I think Mozilla should go with historical behavior and
define an authorization space as the combination of the realm value plus the
root URL.  I cannot see where this would be any kind of security risk.
the zope authentication bugs should now be fixed... marking WORKSFORME. 
please reopen if the problem can be demonstrated using a recent nightly build.  thx!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
I waited until 0.9.9 to test this and the bug persists, and is not listed as a
known issue. Will the fix be included in a milestone release?

The behavior: In cases where the server would give a non 401 response to
anonymous users, and the user has already been identified in another path on the
same server, Mozilla will act as if the user is anonymous.

My test case: Zope 2.5.0, trying to edit a Page Template at the root. After
logging in from a url such as http://myserver/manage/ it will fail, and after
http://myserver/manage it will succeed. (this is also a Zope bug, fixed in other
Zope releases: had zope returned 401 Mozilla would have sent back the
authentication info, but there are many cases where anonymous users *should*
recieve a non 401 alternative response.) 
noa: can you give a better description of the steps to reproduce the problem you
are seeing?  though i suspect you really are just seeing a problem w/ zope or a
problem resulting from a misconfiguration of zope... i'd like to better
understand what you are trying to do... cuz it might be something we can work
around on the browser side.  thx!
Steps for reproducing the bug:
1) install Zope 2.5.0, take note of the admin username/password
2) run Zope, say on default port 8080
3) visit with mozilla http://localhost:8080/manage/ (slash at end is important)
4) log in with the admin/password from step one
5) click on standard_template.pt 
at this point mozilla will pretend you are anonymous (because you logged in at
/manage/ and not at / ) Zope will respond as if the user is anonymous, in this
case this will be an error message, but without a 401 header (zope 2.5.0 bug),
so mozilla will accept the response and never send the authentication info. (If
zope had sent the correct header, as does 2.5.1, mozilla would have responded to
the 401 and sent the authentication info)
6) restart mozilla
7) visit with mozilla http://localhost:8080/manage (no slash)
8) log in with the admin/password from step 4
9) click on standard_template.pt
Mozilla will Identify you with the username/password and you will get the
correct page.

The question is why does mozilla not send automatically the username/password
entered in /manage/ , but waits for a 401 to do so?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
the reason why mozilla doesn't automatically send the username/password is
because it doesn't know that that is ok to do.  from RFC 2617 section 2:

   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge. A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.

in other words, the HTTP spec prevents mozilla from working around this bug in
zope 2.5.0, so you'll need to upgrade zope.

marking WORKSFORME
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
Here's why many people are not happy with this behavior, and do not use mozilla
as a result:

It means that whenever a site wants to give one response for an authenticated
user, and a different response for an anonymous user, (a classic example: a link
to the management interface on the sidebar of each page of a site) then the
authentication must be done at the root level. 

The HTTP spec suggests to automatically send the authentication from the
original path to deeper paths, how is that in contradiction with sending the
authentication also for higher paths? this is a service to the user, like
remembering his password. why would he ever want to be anonymous on a higher
level? (giving him a "logout" option would be even cooler)

In what use case would it possibly not be ok? if the password is wrong for the
root level, it will fail anyway, so that's not an issue. What is the advantage
of first trying to go as anonymous, and then trying to send a password, but only
in case of a 401?

The user already knows the username/password, so this isnt a security issue either.

Also, not that I'm using this as an argument for anything, but other browsers
send the info automatically..
noa:

This is a security/privacy issue... sending username:password in plain text to
random websites is not a good idea, wouldn't you agree?  Mozilla has no way of
knowing that

  http://www.foo.com/joe/

is in the same "protection space" (as defined by RFC 2617), as

  http://www.foo.com/bob/

or even

  http://www.foo.com/

for that matter.

Zope considers its behavior a bug, and so does Mozilla.  If users are annoyed by
this, that is unfortunate, but I believe they would be even more annoyed if they
discovered Mozilla sending their username:password for one site to another site.
 That's why Mozilla should not attempt to work around this Zope bug in the
manner in which you suggest.
Darin, if that's the case, then Mozilla needs to stop sending the auth outside 
the protection realm when challenged.  Otherwise, I could challenge at 
www.foo.com/bob with the same HTTP realm value, and get the credentials sent to 
me.  Should I open a new bug for this?

Incidentally, I am not convinced that RFC 2617's behavior is correct, but 
obviously here is not the place to argue it.  I am taking it up with the 
appropriate RFC people.
Matt: If you are sending the *same realm* for www.foo.com/bob/ as for a
previously authenticated www.foo.com/joe/ then mozilla will correctly try and
reuse the same authorization. There is no problem here (neither with mozilla nor
with the spec)
Matt:

point well taken, but you have to distinguish what mozilla does in response to a
401 from what it does when sending the initial request.  at the point of issuing
the initial request, mozilla doesn't know that it'll be challenged, but
according to the spec, mozilla can assume that it will be challenged and send
prior authorization if the path is below an already authenticated path.  it
doesn't say that we can or even should send authorization tokens on every
request to a server just because we were previously challenged by that server.

when we get a 401, the situation is different.  now we know that we've been
challenged, and can be more aggressive about using credentials from our auth
cache.  this is what the RFC suggests, and so it's what mozilla implements.

that said, you raise a very good point, which is if /bob/ can learn /joe/'s
realm (which is easy to do), it can easily cause a 401 w/ the same realm string
and thereby acquire the user's credentials.  what can i say... that's
unfortunate.  IMO this is just one more reason not to use Basic auth when the
username:password is sensitive.  digest auth does not have this problem.

bottom line: let's not make the security hole that is Basic auth any larger.

websites can easily work around this behavior.
the only way /bob/ can use /joe/'s realm is if the /bob has some web-admin
access to setting up realms on /bob/ At that point 'bob' already has access to a
machine which is hosting /joe/ so all bets are off... 
gagan: provided /bob/ can setup an auth realm using .htaccess or whatever, you
could sniff the realm from a 401 response after visiting /joe/, and then use the
same realm for accesses to /bob/... right?
darin:  I reluctantly agree. (-:  I am still going after the RFC authors tho.  
They should have allowed server authors to specify the protection realm in the 
challenge.  But yeah, Basic should go away too...

gagan:  I'm pretty sure you can send a challenge with an arbitrary realm from a 
generic CGI.  In any event, most web servers don't pass the authorization 
header with the username:password to their programs anyway (I know with Apache, 
for instance, you must specifically configure Apache to do this if you need 
it.)  And to get /joe/'s realm is a real piece of cake, like darin says, just 
visit the 401 resource and sniff the returned value.
yes if a website is that lame in allowing individual .htaccess control. Using
.htaccess to control different realms is a really bad idea if you don't want
users to share directories cuz of the exact same reason you described. 
1) Our request does not contradict RFC, (at least not any more than the current
behavior, which will send the info anyway after a 401) because RFC just makes a
suggestion about the deeper paths, and doesnt even talk about the highr paths.

2) If it's a privacy issue, at least there should be a way for the user to stop
basic auth from being automatically sent (401 or no 401) to higher paths. The
current situation just gives a false sense of security. 

3) We all agree basic auth is bad, but this is not the way to fight against it.
It is still in use, and it shouldnt be a reason to cripple Mozilla. Everyone I
know who has experienced this interpreted it as "Mozilla's has problems with
basic auth". because they couldnt figure out why sometimes it works and
sometimes it doesnt.
noa:

so i tested some other browsers to see what they do, and here's what i found:

browser         sends credentials outside "protection space" on initial request
-------         ---------------------------------------------------------------
nav 4.75        no
IE 5.1 (Mac)    yes
IE 6 (Win)      no

what browser are you comparing mozilla against?
Nescape communicator 4.76 is what I got right here, it automatically sends to
higher paths. I'll check with some others and report back.

whoops!  sorry, when i reported the result for nav 4.75, i was really testing
nav 4.78 (under linux)... hmm... so, it sounds like 4x changed its policy on
this issue at some point.
You need to log in before you can comment on or make changes to this bug.