httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject RE: quick_handler hook is completely bogus.
Date Wed, 31 Jul 2002 13:10:24 GMT

> Ryan Bloom wrote:
> > 1)  If I have a page that I have served and it gets put in the cache,
> > then it will be served out of the quick_handler phase.  However, if I
> > then add or modify a .htaccess file to deny access to that page, then my
> > changes won't be honored until the page expires from the cache.
> True, and from any other cache along the chain between browser and server.
> > This is
> > a security hole, because I don't know of anyway to invalidate cached
> > pages.
> Sort of, leaning towards yes. I don't believe it's a hole as such
> (because behaviour is consistent with any number of caches) however it
> does violate the principle of least astonishment - when Apache's config
> changes, Apache should be serving pages that correspond to that config
> immediately, not later after cache expiry.
> > 2)  If I have a page that uses access checking to ensure that only
> > certain people can request the page, the cache_filter will put it in the
> > quick handler.  However, the page may not be allowed to people who will
> > request it from the cache.  I may be wrong about this one, but I see how
> > the cache disallows pages that require authentication.  I do not see how
> > it can disallow caching of pages that require access_checking.
> Does the cache store pages protected by access control? If it does, the
> cache should respond to Cache-Control: private headers set by the auth
> modules (does Apache set these headers correctly?), OR - each user's
> page could be considered a variant of the URL, which means the page gets
> cached, but a version for each user, guaranteeing that user A does not
> see pages from user B, ever.
> Hmmm... this could be a good thing for people who have password
> protected websites that are expensive to generate. The cache could still
> cache password protected stuff, but safely.

mod_cache does not currently cache password protected content, though it
could be made to relatively easy by defining a handler for mod_cache and
serving password protected content from the handler. This is a feature I
intend to implement.

> > 3)  It isn't possible for a module author to circumvent the
> > quick_handler phase.  If I write a module that doesn't want to allow the
> > quick_handler phase, for security reasons, I can't enforce it.
> True.

That is true of all the other hooks as well. It appears you are judging the
quick_handler much more harshly that the other hooks which can just as
easily be abused to the detriment of the server security. Use the hook
correctly and there are no security exposures. I think we could easily
modify the server to enable quick_handler to return one of three or four
values DONE, DECLINED, OK or an HTTP error. Returning DONE would allow the
server to ignore calling other module's quick_handlers (if there are any).

> > While I understand that we are giving people a lot of rope and asking
> > them to use it wisely, this phase gives too much rope, and invites
> > people to hang themselves.
> I think quick_handler should not be removed, but rather moved to before
> the handler, but after the auth.

I strongly disagree. The whole idea of the quick_handler is to bypass
location_walk, directory_walk, access and auth checking. The overhead for
all these steps adds up.  I also have a prototype ESI fragment
cache/assembler that relies on the quick handler being right where it is in
the request cycle.


View raw message