> 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 directory. > 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. <mikeReceived on Wednesday, 20 December 1995 09:07:44 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC