httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: config/315: <LIMIT> causes two password queries unless given fqdn.
Date Sun, 06 Apr 1997 06:05:04 GMT
On Sat, 5 Apr 1997, Alexei Kosut wrote:

> On Sat, 5 Apr 1997, Marc Slemko wrote:
> > The answer to this (psst... another FAQ?) is probably that Apache is
> > issuing a redirect which causes it to be a different server as far as the
> > client knows, making it reprompt for the name.
> > 
> > If the directory /foo/ is protected, is there any reason why a request for
> > /foo needs to return a 401?  Would it cause a security hole if it just
> > returned the redirect to /foo/ without requiring authentication?  That
> > would eliminate this frequent problem; Netscape Commerce 1.1 avoids the
> > problem by doing things this way.
> I think that would be a security problem (not to mention a bit tricky
> given Apache's authentication model), for the same reason we return
> 401/403 and not 404 when there is an unauthorized request for a
> non-existant file: It tells a potentially unwanted visitor something
> about a private area of your site, namely that a file doesn't
> exist. This means that if you know that the server behaves that way,
> you can quickly find out which files *do* exist (they return 401/403
> instead of 404). Having Apache return 301 instead of 401/403 would
> produce the same problem: it would then be possible to find out if a
> directory existed or not, simply by testing its URL sans slash.

I was thinking more along the lines of sending a 301 right away instead of
a 401 based on the authorization required for the parent directory.  If
you treat "foo" as a file in the parent directory and "foo/" as a
subdirectory, I think it makes sense to allow "access" (ie. a redirect) to
"foo" if access would be granted to the parent of the foo directory.  

I agree with you that doing what I suggest for _any_ directory would give
away information that should not be given away.  As you also point out,
implementation is another issue. 

This is quite an annoying problem when trying to use authentication on a
server that people refer to by more than one name.  Guess you could fake
it to some degree by using "Host:" based virtual hosts.  You could also
hack the server to send a redirect to the real ServerName if it gets a
request that requires authentication but has a "Host:" header with some
other name in, but neither of those are real solutions.  Yes, yes... there
are no real solutions while being forced to stick with basic
authentication by silly browsers.

View raw message