Re: partial URLs ? (was <p> ... </p>)

According to Arjun Ray:
> From http-wg-request@cuckoo.hpl.hp.com Wed Dec 20 15:49:15 1995
> Received: from dehn.math.nwu.edu (root@dehn.math.nwu.edu [129.105.81.5]) by hopf.math.nwu.edu (8.6.10/8.6.9) with ESMTP id PAA18157 for <john@hopf>; Wed, 20 Dec 1995 15:49:14 -0600
> Received: from hplb.hpl.hp.com (daemon@hplb.hpl.hp.com [15.255.59.2]) by dehn.math.nwu.edu (8.6.12/Math.nwu-v8) with ESMTP id PAA16731 for <john@math.nwu.edu>; Wed, 20 Dec 1995 15:50:13 -0600
> Received: from cuckoo.hpl.hp.com by hplb.hpl.hp.com; Wed, 20 Dec 1995 21:49:06 GMT
> Received: from http-wglistexploder by cuckoo.hpl.hp.com
> 	(1.37.109.16/15.6+ISC) id AA123925977; Wed, 20 Dec 1995 21:46:17 GMT
> Date: Wed, 20 Dec 1995 16:45:19 -0500 (EST)
> 
> On Wed, 20 Dec 1995, Daniel W. Connolly wrote:
> 
> > What's _not_ cool is to try to sidestep the processing of .. on the
> >client side;  that is, to just combine the base and HREF into: 
> > 
> > 	http://www.foo.com/a/b/../gifs/btnhome3.gifs
> > 
> > (which is _not_ a well-formed HTTP url) and send:
> > 
> > 	GET /a/b/../gifs/btnhome3.gif HTTP/1.0
> > 
> > This is illegal because it is a potential secruity risk. Consider a server
> > whose document root is /usr/local/etc/httpd/docs/ and a client who sends:
> > 
> > 	GET /../../../../etc/passwd HTTP/1.0
> > 	Accept: text/plain
> > 
> > a naive server implementation might just do:
> > 	fopen("/usr/local/etc/httpd/docs//../../../../etc/passwd")
> > and give away a bunch of sensitive info.
> > 
> > In stead, any server that sees /../ in the HTTP path is supposed to
> > issue a 403 Unauthorized response. (Is this in the HTTP specs somewhere?
> > YIKES! I can't find it in draft-ietf-http-v10-spec-02.txt!!!
> 
> I think this is illegal simply because it's not a well-formed URL. The 
> question, then, is what the server should do about it.
> 

As I recall the draft RFC for URL's specifies that certain characters
(like space) are forbidden, certain (like '?') have special meaning
and otherwise the "path" part of a URL is an opaque string (which, in
particular, may have nothing to do with a path).  Neither '/' nor '.'
are forbidden or have special meaning.  They do have special meaning
*for some implementations* and no special meaning for others.
Likewise the colon may have special meaning for some implementations
and not for others.

The fact that certain strings may represent securtity risks for
some implementations does not automatically make them illegal.
I don't believe that "/../" is forbidden in HTTP URL's.  If
I am wrong I would be interested in a reference. 

It would, of course, be quite reasonable for the HTTP spec to have
a UNIX-centric warning to implementors that they should make this
string illegal for their implementation (or risk the consequences).

John Franks

Received on Wednesday, 20 December 1995 21:00:42 UTC