net/http: document filepath sanitization for ServeFile

[FlorianUekermann]

This is a petty formulation issue, but the subject is quite sensitive so I thought I would bring it up. The documentation for http.ServeFile(w ResponseWriter, r *Request, name string) states that name needs to be sanitized to prevent ascension into parent directories. It further states that ServeFile rejects requests that contain ".." as path elements.

I assume the implication of both statements combined is that patterns like

http.ServeFile(w, r, filepath.Join(".", r.URL.Path))
http.ServeFile(w, r, filepath.Join("dir", r.URL.Path))

are "safe" in the sense that ascension into the respective parent directories is not possible.
However this is not obvious from the current documentation as there may more obscure ways of ascending than ".." that are less obvious (I am honestly not sure).

Imo it would be a good idea to state explicitly whether the file path in the above patterns is sufficiently sanitized or not because I see only two scenarios:
-If the patterns above are not safe the current documentation may cause security problems
-If the patterns are safe some users won't take advantage of this great function because it is not explicitly stated (this is me right now).

[odeke-em]

/cc @bradfitz

[bradfitz]

Sorry, I lost this bug.

r.URL.Path can arrive with ".." in it, so it's not safe to use with filepath.Join directly to ServeFile.

Consider: https://play.golang.org/p/5GlPtcESJm

I suppose we could document that r.URL.Path can contain "..". Would that be sufficient?

[FlorianUekermann]

ServeFile prevents your attack by checking the URL.Path. See: https://play.golang.org/p/kVXs8aOBNz

Note that in the second example the return value of Join doesn't contain any "..", since Join "cleans that up", but ServeFile checks the URL.Path directly. It seems to me that ascension to parent directories can't be caused by the URL, which would make the pattern I used above safe.

[hawkinsonb]

Also note that this vulnerability is even more present when using templates. Our Example: a path from some predetermined directory is passed through the URL via ?path=/in/side/directory. parsed with URL.Query(), into some function to return the contents of our file. Our options to read the contents of this would be ioutil.ReadFile(filepath.Join(directoryPath, filePathFromDirectory)) or ioutil.ReadFile(directoryPath + "/" + filePathFromDirectory).

However ioutil.ReadFile(filepath.Join(directoryPath, path)) with the query ?path=../../../etc/passwd grabs the contents of the passwd file and outputs it into the template leaving the host vulnerable. We're using directoryPath + "/" + filePathFromDirectory to come up with our path as it's not exposed, but this is not "proper" way to handle this. This is without using ServeFile where the current layer of security lies, shouldn't there be some layer of protection at the *http.Request level?