Hi Anthony:

In message <1666126880.20160708143147@inbox.ru>,
Anthony writes:
>I  think  we  can  just throw away a parameter with double dot inside.
>[...]  There is no need to parse it by path
>rules.
>
>I thing something like
>
>              if name.find("..") != 0:
>                return # will raise invalid template
>
>will be enough.

It looks like a %2E in the url is converted to periods by the time I
get to _find and do the check above. So a simple attempt to defeat it
looks like a check for .. should work.

My patch accidently reimplemented the code that is used for sanitizing
the url's for serving up static files (@@file paths). I discovered the
code for checking static files after I posted my code. Static file
code uses normalize not realpath, but the idea is the same.  I'll bet
when it was written realpath didn't exist. However static_file is
called *a lot less* than the templating code, and I like the
speed/simplicity of searching for '..' but not if it allows another
attack vector.

I am still concerned if something in the url could be slipped
past. High bit encoded characters that get stripped during the path
conversion so the path ends up with .. even though it's not encoded
that way in the name. Maybe some conversion function will change the
path string before it gets passed to an open function or something.

I may just be paranoid, but I remember path traversal bugs related to
encoding issues.

https://www.owasp.org/index.php/File_System#Path_traversal suggests If
forced to use user input for file operations, normalize the input
before using in file io API's, such as
http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#normalize().

Ditto in https://en.wikipedia.org/wiki/Directory_traversal_attack

Anybody else want to chime in here?

(Also Anthony, can you trim your responses. I realize using a cell
phone makes this a pain but if you can trim, please do. Especially if
you are top posting and don't need to include the original post as the
tracker doesn't trim quoted material.)

Thanks for your feedback. It nicely addresses the performance issue
that I was worried about.