Closed
Bug 110705
Opened 23 years ago
Closed 22 years ago
basic auth no longer being automatically presented
Categories
(Core :: Networking: HTTP, defect)
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...
Updated•23 years ago
|
Comment 1•23 years ago
|
||
I am seeing this too, on 20011221 (newer builds for solaris seem to be slow in coming...) I'd confirm if I could :-)
Comment 2•23 years ago
|
||
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?
Comment 3•23 years ago
|
||
This is NOT fixed. I can't figure out what triggers the bad behavior, but it still exists in 2002011410.
Assignee | ||
Comment 4•23 years ago
|
||
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...
Comment 6•23 years ago
|
||
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.
Assignee | ||
Comment 7•22 years ago
|
||
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.)
Assignee | ||
Comment 9•22 years ago
|
||
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!
Comment 10•22 years ago
|
||
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 → ---
Assignee | ||
Comment 11•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 12•22 years ago
|
||
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..
Assignee | ||
Comment 13•22 years ago
|
||
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.
Comment 14•22 years ago
|
||
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.
Comment 15•22 years ago
|
||
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)
Assignee | ||
Comment 16•22 years ago
|
||
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.
Comment 17•22 years ago
|
||
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...
Assignee | ||
Comment 18•22 years ago
|
||
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?
Comment 19•22 years ago
|
||
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.
Comment 20•22 years ago
|
||
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.
Comment 21•22 years ago
|
||
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.
Assignee | ||
Comment 22•22 years ago
|
||
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?
Comment 23•22 years ago
|
||
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.
Assignee | ||
Comment 24•22 years ago
|
||
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.
Description
•