httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Dropped: [inq] short, concise, and to the point
Date Wed, 04 Oct 2000 16:53:38 GMT
IMO, I'd rather see security based on locations rather than where it appears
in the filesystem. That allows people more freedom in placing their data
into the FS wherever/however they'd like (or even moving it into a database
or something). Once the security is tied to a specific directory, then admin
changes like that must also have corresponding changes in the .conf file.

hmm... I mean, there will be changes in the .conf whenever you alter how
content is served, but doing it by location can be much easier. Consider if
you have /a/b, /a is read-protected, and you need to move "b" to a new FS
position:

a) Location-based security continues to protect /a and /a/b; the only change
   would be adding a new Alias

b) A duplicate Directory entry would be needed for /a/b's new FS
   position; now you have two <Directory> blocks to protect your system: one
   for /a's FS position, and one for /a/b.


Below, you state that a person can add slashes or . or .. into the URI and
bypass the Location check. Is that true? I understand the case change thing
(e.g. Alias /a /some/where, then apply security to /a/b; accessing via /a/B
will bypass the security). Therefore, doesn't this only apply to systems
with case-insensitive filesystems? Can't we explain it from that direction,
rather than moving people away from <Location> and towards <Directory> ?

When you say the mod_dav doc contradicts this... how do you mean? I don't
any specific recommendation one way or another; it uses <Location> in the
examples, but that is all. Or is it because you are considering where the
content may not be in the filesystem, and thus can only be protected using
<Location>?

Cheers,
-g


On Wed, Oct 04, 2000 at 09:46:49AM -0500, William A. Rowe, Jr. wrote:
> Ok... I've spent the last 12 hours mulling this over.
> 
> I'm dropping the issue in favor of the following additional
> documentation in our existing documentation on using 
> <Directory > and <Location > directives.  However, existing 
> documentation and examples for mod_dav and the phf abuse 
> interceptor contradict this recommendation:
> 
>   <Location > blocks should never be used to enforce security
>   over any URL the server can resolve without the <Location >
>   block.  Do not try to set Require or Deny options for a file 
>   through the use of a <Location > block, always enforce security
>   through the appropriate <Directory > or <Files > block.
> 
>   There are several simple ways that a malicious user may bypass
>   the <Location > block, including adding slashes, . or .. to the
>   URL, or possibly by changing the case of the URL.  Apache cannot
>   interpret these manipulations (except as noted for mod_proxy), 
>   since a <Location > is always a literal, precise resource name,
>   and <Location > URLs are always case sensitive.
> 
>   <Location > blocks should only enforce security of the URL it
>   itself exposes.  That is, any <Location > with a SetHandler or
>   DocumentRoot directive can control the access to that URL space.
>   The resource exposed by the <Location > block will not be found 
>   if the user attempts to bypass the proper URL, so the security
>   of those resources are not compromised.
> 
>   If you attempt to use <Location > blocks to protect the security
>   of a resource defined outside of the <Location > block, either
>   with wildcards or regular expressions, you must understand the
>   exact consequences and potential exploits before you proceed.
> 
> Anyone feel this is appropriate/sufficient warning?
> 
> > -----Original Message-----
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> > Sent: Tuesday, October 03, 2000 10:13 PM
> > To: new-httpd@apache.org
> > Subject: RE: [inq] short, concise, and to the point
> > 
> > 
> > > From: Fielding, Roy [mailto:fielding@eBuilt.com]
> > > Sent: Tuesday, October 03, 2000 1:16 PM
> > > 
> > > All locations are case sensitive.  Always.  Regardless of platform.
> > 
> > I'm very, very unclear here.  What are we defining as a location?
> > 
> > If a <Location > refers to the URI, and I have a lookup cgi on unix 
> > that is handling the /lookup location, and the data is case 
> > insensitive,
> > then I may wish to add a block such as:
> > 
> > <Location /lookup/home-phone>
> >   require group management
> > </Location>
> > 
> > The lookup script accepts home-phone, or HOME-PHONE, without 
> > complaining.
> > 
> > I guess I'm asking, why the absolute opposition to accomodating 
> > case-netural URI locations for those cases that are affected?
> > You maintain that a location is case sensitive, but I'm arguing
> > that not every system/namespace is case sensitive.
> > 
> > Perhaps this could be (like regex parsing) a syntax such as 
> > 
> > <Location ? /uri>
> > 
> > where ? is a case-insensitive flag.  I am -not- suggesting 
> > that Location
> > must always do case-neutral comparison!
> > 
> > > What we need is a way for Directory to indicate how the filesystem
> > > should be checked, such that case-sensitive filesystems do 
> > not suffer
> > > from the extra name canonicalization required of case-insensitive
> > > filesystems.
> > 
> > They don't today, do they?  Win32/OS2 lowercases these <Directory >
> > block tags and the request name, and uses those canonical names
> > for comparison.
> > 
> > Agreed that we may have a unix share on an NT server, or an NT volume
> > mounted to a unix file system, that messes up everything :-/
> > 
> > > This has to be part of Directory because of remote mounting.
> > 
> > Yes - <Directory > is a filesystem tag, and should become smarter
> > about which sections are case sensitive vs. insensitive.  I'm simply
> > addressing the complaint that <Location > blocks are meaningless on
> > Win32/OS2 systems, and have been for 2 years.
> > 
> > Bill
> > 
> > > > -----Original Message-----
> > > > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> > > > Sent: Monday, October 02, 2000 11:23 PM
> > > > To: new-httpd@apache.org
> > > > Subject: [inq] short, concise, and to the point
> > > > 
> > > > 
> > > > 
> > > > Q:  Would there be any objection to a new directive for 
> > <Location >
> > > > processing to -allow- case insensitivity?  e.g.
> > > > 
> > > > LocationIsCaseInsensitve On
> > > > 
> > > > Where the default, of course, is off?
> > > > 
> > > 
> > 

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message