Re: partial URLs ? (was
William C. Cheng (firstname.lastname@example.org)
Wed, 20 Dec 1995 14:48:28 -0500
Mike Meyer <email@example.com> wrote:
| > 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:
| It's a potential security risk on *SOME* systems. Works fine on mine.
| You're quite welcome to fetch <URL:http://www.phone.net/home/mwm/../>,
| which will get index.html from the directory ".." in my public html
| > 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?
| No. A server should be allowed to issue "403 Unauthorized" (or "404
| Not Found") for any URL that the server considers insecure. On Unix
| systems, I'd certainly consider "/../" to be such a string. On other
| systems, another syntax (for instace "//") might be used for that end,
| and the server is perfectly justified in rejecting any request
| containing that string.
| Yes, having ".." (or "") as a path component creates interesting
| problems in writing relative URLs, and is probably a bad idea on any
| server. Yes, an attempt to access "../../../../etc/passwd" is probably
| someone trying to break into the system. However, it's up to the
| people running the server, not the spec, to decide what is and is not
| a security problem and deal with them. Unless some request can be
| shown to create problems independent of the underlying platform, the
| spec should not make any request illegal.
I like Dan Connolly's response that a well-behaved Client should NOT
request any URL with ../ in it because it may get a 403 response.
Bill Cheng // Guest at Columbia Unversity Computer Science Department
WWW Home Page: <URL:http://www.cs.columbia.edu/~william>