You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2002/07/30 21:40:56 UTC
quick_handler hook is completely bogus.
I realize that this is a strong statement, but I believe that I can back
it up. My reasons for not liking this hook at all:
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. This is
a security hole, because I don't know of anyway to invalidate cached
pages. (This one if from a conversation with wrowe). [ I guess it
might be possible to clear the cache with a graceful restart. ]
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.
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.
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 believe that this hook should be removed, and all content should be
served out of the handler phase. If we are looking to remove some
request phases, then we should make it possible to avoid individual
phases when serving requests, not completely skip all of them.
Ryan
----------------------------------------------
Ryan Bloom
rbb@covalent.net rbb@apache.org
RE: quick_handler hook is completely bogus.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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.
Bill
Re: quick_handler hook is completely bogus.
Posted by Graham Leggett <mi...@sharp.fm>.
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.
> 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.
> 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.
The point behind quick_handler to to make sure the handler runs as close
to first as possible.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm
"There's a moon
over Bourbon Street
tonight..."
Re: quick_handler hook is completely bogus.
Posted by Graham Leggett <mi...@sharp.fm>.
Ryan Bloom wrote:
> mod_proxy doesn't use the quick_handler.
Not mod_proxy, mod_cache.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm
"There's a moon
over Bourbon Street
tonight..."
RE: quick_handler hook is completely bogus.
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Bill Stoddard [mailto:bill@wstoddard.com]
>
> > I'm approaching this from a caching perspective, so when a module
uses
> > quick_handler for non-caching mechanisms, my comments do not apply
but
> > here's an option:
> >
>
> FWIW, quick_handler was added to the server to enable more efficient
> content
> caching. Graham modified mod_proxy to use it (and it seems a
reasonable
> use
> to me). This use alone justifies the existence of the quick_handler
hook
> IMHO.
I must be missing something:
C:\opensource\httpd-2.0\modules\proxy>grep "quick_handler" *
grep: CVS: Is a directory
grep: Debug: Is a directory
mod_proxy doesn't use the quick_handler.
Ryan
RE: quick_handler hook is completely bogus.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> I'm approaching this from a caching perspective, so when a module uses
> quick_handler for non-caching mechanisms, my comments do not apply but
> here's an option:
>
FWIW, quick_handler was added to the server to enable more efficient content
caching. Graham modified mod_proxy to use it (and it seems a reasonable use
to me). This use alone justifies the existence of the quick_handler hook
IMHO.
Bill
Re: quick_handler hook is completely bogus.
Posted by Brian Degenhardt <bm...@mp3.com>.
I'm approaching this from a caching perspective, so when a module uses
quick_handler for non-caching mechanisms, my comments do not apply but
here's an option:
What if modules were required to set the Vary: header appropriately
and have mod_cache_* honor it? This way, you're caching problem is
fixed for not only stuff that quick_handler screws up but for stuff
that any downstream proxy screws up. If you're module absosmurfly has
to run on every request, do "Vary: *" and you're problem is solved.
-bmd
On Tue, Jul 30, 2002 at 12:40:56PM -0700, Ryan Bloom wrote:
>
> I realize that this is a strong statement, but I believe that I can back
> it up. My reasons for not liking this hook at all:
>
> 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. This is
> a security hole, because I don't know of anyway to invalidate cached
> pages. (This one if from a conversation with wrowe). [ I guess it
> might be possible to clear the cache with a graceful restart. ]
>
> 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.
>
> 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.
>
> 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 believe that this hook should be removed, and all content should be
> served out of the handler phase. If we are looking to remove some
> request phases, then we should make it possible to avoid individual
> phases when serving requests, not completely skip all of them.
>
> Ryan
>
> ----------------------------------------------
> Ryan Bloom
> rbb@covalent.net rbb@apache.org
>
>
RE: quick_handler hook is completely bogus.
Posted by Ryan Bloom <rb...@covalent.net>.
> > 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. This is a security hole, because I don't know of anyway to
> > invalidate cached pages. (This one if from a conversation with
> > wrowe). [ I guess it might be possible to clear the cache with a
> > graceful restart. ]
>
> How does this differ from the document being cached anywhere
> else? Such as in squid, or a proxy, or the client's cache? Depending
> upon the cache-control fields in the original response header,
> the cache engine may not even do a conditional GET.
I can accept that argument. Although, from a user's point of view, I
would consider them different specifically because in the cache module,
everything required to serve the page is in the same place.
> > 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.
>
> I thought the caching modules didn't cache anything that required
> either access or auth/authz checking. FirstBill?
I read through the code, and I see where the auth/authz decision is
made. However, I can't see where the access control decision is made.
If it is there, then I would be more than happy to remove this issue.
> > 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.
>
> How can a module author disallow *any* phase? That's a core
> function, not up to modules to decide..
In every other hook in the server, I can generally return some value
that makes the phase stop processing, while allowing the request to
finish. For many phases, that code is DONE, for others it is OK or
DECLINED. With quick_handler, there is nothing I can do.
Ryan
Re: quick_handler hook is completely bogus.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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. This is a security hole, because I don't know of anyway to
> invalidate cached pages. (This one if from a conversation with
> wrowe). [ I guess it might be possible to clear the cache with a
> graceful restart. ]
How does this differ from the document being cached anywhere
else? Such as in squid, or a proxy, or the client's cache? Depending
upon the cache-control fields in the original response header,
the cache engine may not even do a conditional GET.
(Not trying to be obstreperous; asking a serious question.)
> 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.
I thought the caching modules didn't cache anything that required
either access or auth/authz checking. FirstBill?
> 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.
How can a module author disallow *any* phase? That's a core
function, not up to modules to decide..
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
RE: quick_handler hook is completely bogus.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> I realize that this is a strong statement, but I believe that I can back
> it up. My reasons for not liking this hook at all:
>
> 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. This is
> a security hole, because I don't know of anyway to invalidate cached
> pages. (This one if from a conversation with wrowe). [ I guess it
> might be possible to clear the cache with a graceful restart. ]
.htaccess applys to things residing in the file system (both physically and
logically). quick_handler is by definition a hook that can only serve
content out of URL space. mod_cache stores content keyed to the URL. That
content can be dynamically generated or it may be a file out of a file
system (local or remote). If the content is a file out of the file system,
then mod_cache needs to be careful to NOT cache files that have auth or
access protections. Make sense so far? Now here is what I hope will
convince you that quick_handler is no more a security risk (from an
auth/access checking perspective)than having a proxy between you and the
server.
A proxy should not cache content that requires either access or auth
checking. mod_cache uses the exact same algorithms for determining if
content should be cached or not, regardless of whether that content is
generated locally or not, regardless of whether the content is scraped off
the disk or generated dynamically. mod_cache behaves identically to a proxy
cache (because it IS a proxy cache). If you do not have a problem with
proxy caches, then you should not have a problem with mod_cache's use of the
quick_handler hook.
I think this explanation covers 2).
Your turn.
Bill