Return-Path: <new-httpd-owner-new-httpd-archive=hyperreal.org@apache.org>
Delivered-To: new-httpd-archive@hyperreal.org
Received: (qmail 715 invoked by uid 6000); 8 Jan 1998 21:13:49 -0000
Received: (qmail 709 invoked from network); 8 Jan 1998 21:13:48 -0000
Received: from valis.worldgate.com (marcs@198.161.84.2)
  by taz.hyperreal.org with SMTP; 8 Jan 1998 21:13:48 -0000
Received: from localhost (marcs@localhost)
	by valis.worldgate.com (8.8.7/8.8.7) with SMTP id OAA29997
	for <new-httpd@apache.org>; Thu, 8 Jan 1998 14:13:47 -0700 (MST)
Date: Thu, 8 Jan 1998 14:13:47 -0700 (MST)
From: Marc Slemko <marcs@worldgate.com>
To: new-httpd@apache.org
Subject: Re: cvs commit: apachen/src/main http_request.c
In-Reply-To: <Pine.LNX.3.95dg3.980108122610.10676J-100000@twinlark.arctic.org>
Message-ID: <Pine.BSF.3.95q.980108140836.27965K-100000@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Thu, 8 Jan 1998, Dean Gaudet wrote:

> 
> 
> On Thu, 8 Jan 1998, Ben Laurie wrote:
> 
> > Dean Gaudet wrote:
> > > 
> > > This breaks stuff.  Consider:
> > > 
> > >     GET http://abcdef/foo%2fbar
> > 
> > Uh?
> 
> Ok consider GET http://abcdef/foo%2ebar and
> 
> <Directory proxy:http://abcdef/foo.bar>
> 
> The former will is equivalent to the latter but after Marc's change will
> not be considered so.  i.e. security hole. 

os_canonical_filename plays no part in this anyway.  It is bogus to apply
os_canonical_filename to _remote_ URLs because it is _os_; we don't know
what OS the remote runs and these aren't fs paths.

In any case, we _can't_ fully protect against this.

http://site//foo

and

http://site/foo

_could_ refer to two different documents.  It just happens that they don't
on Apache servers.  Pretending they are the same would be bogus.  That may
not be the best examples, there are others.  %-encoding is (generally) a
different case.

url variance sucks, but it is very hard to avoid allowing stuff like this
through the proxy.  How about paths with "/../" in?  Denying such things
at the proxy wouldn't be smart.

> 
> (I switched the example from %2f to %2e so that we don't have to think
> about %2f issues, they're special.)
> 
> Dean
> 
> > 
> > > 
> > > and
> > > 
> > >     <Directory proxy:http://abcdef/foo/bar>
> > >     ...
> > >     </Directory>
> > > 
> > > Of course, this example is already broken by doing this:
> > > 
> > >     GET http://abcdef:80/foo/bar
> > > 
> > > Or at least I think it is.
> > > 
> > > Perhaps we should take this time to completely blow away the "special"
> > > proxy r->filename crap.  These things are URIs and should never see
> > > the light of day in the filesystem code.  They're handled just fine
> > > by <Location>.
> > 
> > doubleplusone.
> > 
> > Cheers,
> > 
> > Ben.
> > 
> > -- 
> > Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
> > Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
> > and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> > A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
> > London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache
> > 
>