httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@nueva.pvt.k12.ca.us>
Subject Re: 1.2b3 release
Date Mon, 23 Dec 1996 22:03:18 GMT
On Mon, 23 Dec 1996, Rob Hartill wrote:

(Note: at the bottom of this message is a patch to fix the
multiple-slash problem. If you don't care to read drivel about why
<Files> and MultiViews works the way they do, and why we need another
half dozen API hooks, at least please skip to that.)

> >I haven't seen any response to my patch to fix the overrides in
> ><Files> sections.
> 
> I haven't used <Files> so would rather not comment. Actually I once
> did try using Files but it didn't work the way I wanted, i.e. to act
> on filenames after Multiviews had chosen them.
> 
> <Files *.de>
> 	ExpiresActive off
> </Files>

Yeah. This is actually a "feature" of MultiViews, not a problem with
<Files>. In the URL-to-filename phase, MultiViews leaves the filename
alone, so if you request /filename, the filename gets translated as
/whatever/the/dir/is/filename. MultiViews then comes in at the
type-checking phase - after <Files> has been checked - and changes the
filename. It needs to do this because the URL-to-filename phase likely
will happen after mod_negotiation has already been called (in
http_core, for example), so MultiViews can't kick in.

This is another set of new API hooks we'd talked about wrt
mod_rewrite: instead of the one filename-to-URL hook we have now,
having three: URL-to-URL, filename-to-URL and
filename-to-filename. MultiViews could easily be a
filename-to-filename phase. Then this would work.

Someone should be keeping a list.

> >The multiple-slash thing defintely needs fixing before 1.2.0, since it
> >really is a major security hole (am I the only one who realizes that?
> 
> is there a proposed fix ?
> 
> Lot's of people expect multiple /s so I suppose the only solution is to
> reject requests if a file exists and the URL part up to the filename
> contains //+

That wouldn't work too well, because the URL and filename don't have a
one-to-one relationship.

I did a little more digging into this, and discovered that, in fact,
the <Directory>-parsing code does collapse multiple slashes before
doing its matching - it calles no2slash(), a function I hadn't
remembered existed. This is why we never saw this problem before with
<Directory>.

Here's a patch that fixes <Location> and <Files> (which also is
affected by this) in a similar way. This should fix the problem (I
hope):

Index: http_request.c
===================================================================
RCS file: /export/home/cvs/apache/src/http_request.c,v
retrieving revision 1.32
diff -c -r1.32 http_request.c
*** http_request.c	1996/12/11 05:16:08	1.32
--- http_request.c	1996/12/23 22:00:52
***************
*** 381,386 ****
--- 381,392 ----
      int len, num_url = url_array->nelts;
      char *test_location = pstrdup (r->pool, r->uri);
  
+     /* Collapse multiple slashes, if it's a path URL (we don't want to
+      * do anything to <Location http://...> or such).
+      */
+     if (test_location[0] == '/')
+ 	no2slash (test_location);
+ 
      /* Go through the location entries, and check for matches. */
  
      if (num_url) {
***************
*** 439,444 ****
--- 445,453 ----
      core_dir_config **file = (core_dir_config **)file_array->elts;
      int len, num_files = file_array->nelts;
      char *test_file = pstrdup (r->pool, r->filename);
+ 
+     /* Collapse multiple slashes */
+     no2slash (test_file);
  
      /* Go through the file entries, and check for matches. */
  


-- 
________________________________________________________________________
Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/


Mime
View raw message