httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Dropped: [inq] short, concise, and to the point
Date Wed, 04 Oct 2000 14:46:49 GMT
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?
> > > 
> > 
> 

Mime
View raw message