[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO

Glenn Linderman report at bugs.python.org
Fri Mar 16 19:09:57 CET 2012


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Senthil, from you patch, I discovered where the test_httpservers.py lives, and added 

            '/cgi-bin/file1.py/../../a': ('/', 'a'),

to a local copy, and it worked fine against whatever version of the server and tests it was running against... but that was in test_url_collapse_path_split ... I haven't figured out the full environment of the testing, or even if it launches an HTTP SERVER or only unittests particular functions within it, but it seems that that particular test is just testing the one function.  I'm not clear on where the tests actually test the activities of is_cgi or the creation of PATH_INFO, if that occurs. What time I've spent working with Python can be characterized as 99% application, 0.999% Python source to figure out how things work (or fail), .001% test environment (just now). So I'm pretty ignorant of the test environment, although I've spent 30+ years programming, only about 4 has been in Python, and that not full time.

It is not clear to me, though, that the test you added:

    '/cgi-bin/file1.py/PATH-INFO': ('/cgi-bin', 'file1.py/PATH-INFO'),

should be the expected results of _url_collapse_path_split... 

I would expect 

    '/cgi-bin/file1.py/a/b/c/../../d': ('/cgi-bin/file1.py/a', 'd'),

but I don't think it would, with your present patch. It looks like it would return ('/cgi-bin', 'file1.py/a/b/c/../../d') which reintroduces the security problem: the '..' stuff has not been processed. I haven't applied your patch to actually run it, this is just from inspection, and I may have missed something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10484>
_______________________________________


More information about the Python-bugs-list mailing list