ID: 50837
User updated by: info at karlblessing dot com
Reported By: info at karlblessing dot com
Status: Bogus
Bug Type: CGI related
Operating System: Debian 5.0 x86_64 GNU/Linux
PHP Version: 5.2.12
New Comment:
Digging into it quote a bit for future readers of the bug.
The ~ \.php { } matchup as taught by nginx wiki and nginx creator is
indeed insecure if php is to execute the way described above.
Turns out to fix, needs to have something like this:
location ~ [^/.][a-zA-Z0-9_-]+\.php[s]? { }
doing such will 404 on the above /test.txt/fake.php example, but will
still correctly parse path_info.
#50837 CLOSED/BOGUS , no further argument from me. I'll go update the
wiki
Previous Comments:
------------------------------------------------------------------------
[2010-01-25 22:52:01] [email protected]
PHP walks back through the script_filename it is passed and tries to
find the script to execute. Once again, it is the web server's job to
figure out that a URI doesn't exist. PHP doesn't serve up 404s under
any circumstances. If all your web server is doing is a simple regex
to determine whether something should be executed or not, then your web
server is broken.
------------------------------------------------------------------------
[2010-01-25 22:41:21] info at karlblessing dot com
But PHP is second guessing, it was sent "/test.txt/1.php" as the
original script_filename, that file doesn't exist on the system, so how
does it execute the code if 1.php does not exist? As a result it was
the
parser that move down to the test.txt. Again, note the original
script_filename sent to the parser.
------------------------------------------------------------------------
[2010-01-25 22:38:52] [email protected]
It still doesn't matter. By the time the request makes it to PHP, PHP
is going to execute. I bet you can't reproduce this on a properly
configured Apache server that correctly finds the script and the
pathinfo. Note that in your output your ORIG_PATH_INFO is empty, which
is incorrect. If your URI is /test.txt/1.php and /test.txt exists,
then "/1.php" is the PATH_INFO. Obviously your server doesn't seem to
understand that and determines the URI should be executed by PHP. The
executable part of your URI is /test.txt and it isn't PHP's job to
second-guess that.
------------------------------------------------------------------------
[2010-01-25 22:35:36] info at karlblessing dot com
Regarding the webserver, Nginx matches up php via regex, as per the
wiki provided
http://wiki.nginx.org/PHPFcgiExample#Connecting_Nginx_to_the_running_F
astCGI_Process
location ~ \.php$ { ... } would match up to a php file request.
It is my opinion that the PHP parser should take script_filename
litterally.
That is to say
script_filename = /test.txt/1.php
path_info = no value
shouldn't execute
but
script_filename = /test.txt
path_info = /1.php
should execute, if the webserver indeed sent it those values. In my
case it only sent /test.txt/1.php , which should not have worked
because that filename does not exist on the system.
------------------------------------------------------------------------
[2010-01-25 22:32:36] info at karlblessing dot com
1.php was from a previous test when I typed /1.php after test.txt, if
you type /fake.php after test.txt it'll show fake.txt, just like how I
don't own domain.com, you apparently can't go back and edit the
original.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/50837
--
Edit this bug report at http://bugs.php.net/?id=50837&edit=1
