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

In message <m0tSMkY-000oANC@ccug.wlv.ac.uk>, Jon Wallis writes:
>At 13:19 19/12/95 -0600, BearHeart/Bill Weinman wrote:
>>
>>At 10:40 am 12/19/95 -0800, Walter Ian Kaye wrote:
>>><A HREF="index.html"><IMG SRC="../gifs/btnhome3.gif" ALT="[Home]"
>border=1></A>
>>><A HREF="../map.html"><IMG SRC="../gifs/btnmap3.gif" ALT="[Index]"
>>
>>>(I'm gonna be changing the form and cgi soon, btw, cuz Lynx doesn't like
>>>partial URLs -- tho' Netscape handles this form perfectly.)
>>
>>   The problem with the parial URLs may be the "../" references. 
>>
>>   Some servers, and perhaps some browsers too, disallow them because 
>>they've been abused to get around security measures. 
>
>That really shouldn't be a problem if the system is set up right - but since
>so many systems are poorly set up in terms of security  I can believe it.

I think there are two issues that are getting confused here:
	(1) whether it's OK to use ../../ in an HREF or SRC attribute
	in an HTML document,
	(2) whether it's OK to _send_ ../../ in the path field of
	and HTTP request.

(1) is cool, (2) is not.

For example, if the example above was fetched from http://www.foo.com/a/b/c.html,
then to fetch the [Home] image, the client must combine the value of the HREF
attribute with the base URL as per RFC1808, yielding:

	http://www.foo.com/a/gifs/btnhome3.gif

To access the resource at that address, it makes a TCP connection to port 80
of www.foo.com, and sends:

	GET /a/gifs/btnhome3.gif HTTP/1.0
	Accept: image/*

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!!!

HTTP-WG folks: this should be addressed in the HTTP 1.0 spec, no?

Dan

Received on Wednesday, 20 December 1995 10:38:07 UTC