Re: Guile web server example serving static files

[divoplade <d@divoplade.fr>]

Hello Zelphir,

Le jeudi 17 septembre 2020 à 23:45 +0200, Zelphir Kaltstahl a écrit :
> I finally managed to create an example for using Guile's web server
> and
> serving static files. A rather silly bug kept me for a few days from
> making progress, but finally today I fixed it.
> 
> I tried to implement some security checks about the path of the
> requested static assets. If anyone wants to look at it and point out
> issues with it, I will try to fix it, or you could make a pull
> request.
> If there are any other issues, it would also be great to know them :
> )
> 
> Here is the code in my repository:
> 
> https://notabug.org/ZelphirKaltstahl/guile-examples/src/65ba7cead2983f1ceb8aa2d4eedfe37734e5ca56/web-development/example-03-serve-static-assets
> 
> I tried to comment most stuff, so that the code can be understood
> more
> easily.
> 
> And here is a pointer to the path security stuff:
> 
> https://notabug.org/ZelphirKaltstahl/guile-examples/src/65ba7cead2983f1ceb8aa2d4eedfe37734e5ca56/web-development/example-03-serve-static-assets/web-path-handling.scm#L50

As for why guile avoid reasoning about "paths", see 
https://www.gnu.org/prep/standards/standards.html#GNU-Manuals
https://www.gnu.org/prep/standards/standards.html#GNU-Manuals:

Please do not use the term “pathname” that is used in Unix
documentation; use “file name” (two words) instead. We use the term
“path” only for search paths, which are lists of directory names.

Also, your functions "absolute-path" and "complex-path?" in path-
handling.scm 
https://notabug.org/ZelphirKaltstahl/guile-examples/src/65ba7cead2983f1ceb8aa2d4eedfe37734e5ca56/web-development/example-03-serve-static-assets/path-handling.scm

do not seem to me that they would work correctly when passed something
starting with "../" (as opposed to containing "/../"). I think that
with a little bit of work you could accept "../" in arguments and tweak
path-join to go up (by discarding anything in path1 after the last '/'
and go to the next part, if there is something to discard).

Also I am not sure how it would remove inclusions of '/./' or leading
'./' in the name.

The URI RFC (https://tools.ietf.org/html/rfc3986#section-5) describes
an algorithm in section 5.2. Relative resolution that does the
canonization of an URI relative to an absolute URI (you just need to
ignore the scheme, authority, query and fragment parts and focus on the
path). This is similar to canonicalization of file names, except for
the \\ difficulty. In particular, see 5.2.4, Remove dot segments.

Also, you should refrain from checking if a file exists, because it
could be deleted between your call to file-exists? and when you
actually open the file. Thus, passing the file-exists? test will not
guarantee that the file will exist when you want to use it, and even
less that you will be able to open it and read it.

Finally, you don't need to check if a file name is "safe" at all. the
file procedures do not interpret or substitute variables or ~ or ``
(try it: change directory to /tmp and write to files named ~root,
`pwd`, $PATH, '*', ... just be aware that you will have a hard time
deleting them from bash!), and there is nothing special with files
named as a series of dots. That's good, otherwise you would also need
to check for '%' in mingw and whatever stuff microsoft invented to
change the file name experience.

Best regards,

divoplade