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 Considering general/PR7357: URLs containing invalid paths in combination with .. are served
Date Mon, 05 Mar 2001 16:56:23 GMT
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



Mime
View raw message