Considering general/PR7357: URLs containing invalid paths in combination with .. are served

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Does anyone consider this response acceptable?

127.0.0.1 - - [05/Mar/2001:09:49:11 -0600] "HEAD /manual/misleading-insulting-statement/../suexec.html HTTP/1.0" 200 0

It's possible, due to our current parsing schemas (1.3/2.0) to serve a given
resource with a very misleading URL name.  I'd argue that this should generally 
be a redirect, to address the above PR.  First, it violates Roy's assertions 
that we shouldn't fill up the proxies' namespace with cruft, and second, it 
makes it possible for very misleading names to link to the site.

[Note on Win32 that two [or more] dots is the parent directory, since ambigious
trailing periods are truncated when names are resolved.  (.+)\.* == $1]

The same logic probably applies to /./ or // and since most clients resolve these
issues themselves (when constructing relative links) I'd propose we always redirect
on all of these requests.  Since this introduces potential issues for DAV, among
other things, I'm posting before authoring a patch.  If we can't tollerate the 
potential to break other apps, I'd suggest we also allow this to be toggled, in the 
same [new?] directive as the EtagInode directive.  

I'm thinking FilesystemOptions [[+|-]EtagInode] [[+|-]CanonicalRedirect]

I'm not advocating that we hit the filesystem to validate the resources we '..' out of.
That would be far to costly, and the basis for DNS attack.

Bill

Re: Considering general/PR7357: URLs containing invalid paths in combination with .. are served

["Roy T. Fielding" <fi...@ebuilt.com>]

If, at any time while processing the request, the URL is rewritten such
that a bogus identifier is replaced with an identifier for a valid resource,
then that request should result in a 301 response.  The only exceptions
are internal subrequests for SSI and places where there is a known
browser bug that can't handle the 301.

This isn't in the RFCs -- it is part of the model for how resources
work on the Web (a.k.a. my dissertation).

....Roy

Re: Considering general/PR7357: URLs containing invalid paths in combination with .. are served

[Rodent of Unusual Size <Ke...@Golux.Com>]

"William A. Rowe, Jr." wrote:
> 
> Does anyone consider this response acceptable?
> 
> 127.0.0.1 - - [05/Mar/2001:09:49:11 -0600]
> "HEAD /manual/misleading-insulting-statement/../suexec.html HTTP/1.0"
> 200 0

Yes, I personally think it is acceptable.  Maybe not optimal,
but acceptable.

I am strongly opposed to too much Big Brotherism on the part
of the server.
-- 
#ken    P-)}

Ken Coar                    <http://Golux.Com/coar/>
Apache Software Foundation  <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed"   <http://ApacheUnleashed.Com/>

ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq.  Attend
the only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!

Re: Considering general/PR7357: URLs containing invalid paths in combination with .. are served

[Joshua Slive <jo...@slive.ca>]

On Mon, 5 Mar 2001, William A. Rowe, Jr. wrote:
>
> > On Mon, 5 Mar 2001, William A. Rowe, Jr. wrote:
> >
> > > I'm thinking FilesystemOptions [[+|-]EtagInode] [[+|-]CanonicalRedirect]
>
> Options?  Well we have IndexOptions for indexing, Options for whatever
> http does, and FilesystemOptions for what the file system does.
>

Let me try to clarify one more time.  (My fault; I'm being very opaque
today, in addition to clumsy.)

I think the best solution to the reported problem is something like this
in httpd.conf (untested):

SetEnvIf Request_URI "\.\." funnyurl
SetEnvIf Request_URI "//" funnyurl
Deny from env=funnyurl

(You could also use a RedirectMatch if you want to be more friendly.)

I agree with Ken that it is not good to do too much magic behind the
scenes.

Regarding the syntax issue, I guess my main problem is with the "+|-"
notation which I think people find very confusing.

Jsohua.

Re: Considering general/PR7357: URLs containing invalid paths in combination with .. are served

["William A. Rowe, Jr." <ad...@rowe-clan.net>]

From: "Joshua Slive" <jo...@slive.ca>
Sent: Monday, March 05, 2001 3:35 PM


> On Mon, 5 Mar 2001, William A. Rowe, Jr. wrote:
> 
> > I'm thinking FilesystemOptions [[+|-]EtagInode] [[+|-]CanonicalRedirect]
> >
> 
> Man, I'm really having a hard time operating my email program lately.
> Anyway, I meant to say that the Canonicalization issue should be dealt
> with in httpd.conf.

You think you have it bad... now I'm submitting a mod_dav build patch to
the ms-windows www newslist.  Maybe both our brains need examination :-)

> Even if you do think a new directive is necessary, I'm not sure why you
> would want to perpetuate the confusing syntax of "Options".

Options?  Well we have IndexOptions for indexing, Options for whatever
http does, and FilesystemOptions for what the file system does.

I think the gist is that folks don't want Options expanded.  Better to
make a few groups of options by the area they manipulate (IndexOptions
is a perfect example) and grow from there.  OTOH, I'm not sure we want
dozens of new directives when they can be grouped as flags.

I have no strong opinion on the implementation, just on the facility.

Bill

Re: Considering general/PR7357: URLs containing invalid paths in combination with .. are served

[Joshua Slive <jo...@slive.ca>]

On Mon, 5 Mar 2001, William A. Rowe, Jr. wrote:

> I'm thinking FilesystemOptions [[+|-]EtagInode] [[+|-]CanonicalRedirect]
>

Man, I'm really having a hard time operating my email program lately.
Anyway, I meant to say that the Canonicalization issue should be dealt
with in httpd.conf.

Even if you do think a new directive is necessary, I'm not sure why you
would want to perpetuate the confusing syntax of "Options".

Joshua.

Re: Considering general/PR7357: URLs containing invalid paths in combination with .. are served

[Joshua Slive <jo...@slive.ca>]

On Mon, 5 Mar 2001, William A. Rowe, Jr. wrote:

> Does anyone consider this response acceptable?
>
> 127.0.0.1 - - [05/Mar/2001:09:49:11 -0600] "HEAD /manual/misleading-insulting-statement/../suexec.html HTTP/1.0" 200 0

[...]

>
> I'm thinking FilesystemOptions [[+|-]EtagInode] [[+|-]CanonicalRedirect]
>

I'm a little skeptical about programming all these redirects into
Apache.  I agree that having "one true URL" for each resource is the way
to go, but unless there is a security or basic usability issue, I think
it is best to keep this as transparent as possible.  For example,
why not just include the following in the default httpd.conf: