PHP files being downloaded on condition

Hello, guys,

Another Apache convert here. My 3rd day with nginx and loving it.

I have a nginx + php-fpm setup. The problem is that nginx downloads the
PHP scripts without being parsed instead of passing them to php-fpm - so
far I have discovered that happening only with Chrome’s 14.0.835
(64bit), otherwise it works just fine; there is no difference whether
php-fpm is running or not, so I think it is safe to assume that the
scripts are not being passed to the backend at all. The relevant
(hopefuly configuration):

    location ~ \/[0-9a-zA-Z]+\.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        include fastcgi_params;
        fastcgi_index index.php;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param PATH_TRANSLATED

$document_root$fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
if ($uri ~*
/(images?|system|download|upload|cache|logs?)/(.*/)?[0-9a-z]+.php$)
{
return 404;
}
fastcgi_pass php-fpm;
}

    location /url/ {
            alias /dir/url/;
            index index.php;

            if ($request_uri ~* \.(ico|css|js|gif|jpe?g|png)$) {
                    expires 30d;
                    break;
            }
            if (-f $request_filename) {
                    break;
            }}

Any ideas? How can I prevent such things from happening, providing some
failsafe, disallowing php files’ download? I have so far come out with
that, protecting only possible configuration files:

    location ~ (/\.|.*conf.*\.php) {
        deny all;
    }

But I would like a more generic approach, if possible.

Thank you for your time.

Posted at Nginx Forum:

On Tue, Aug 02, 2011 at 01:35:41AM -0400, Samael wrote:

(hopefuly configuration):
fastcgi_param SCRIPT_FILENAME
location /url/ {

Any ideas? How can I prevent such things from happening, providing some
failsafe, disallowing php files’ download? I have so far come out with
that, protecting only possible configuration files:

    location ~ (/\.|.*conf.*\.php) {
        deny all;
    }

But I would like a more generic approach, if possible.

Your .htaccess style configuration is not easy to understand.
Could you describe in words what you want to get ?


Igor S.

On Tue, Aug 2, 2011 at 12:35 PM, Samael [email protected] wrote:

(hopefuly configuration):

have you tried clearing your browser’s cache?

On Tue, Aug 02, 2011 at 03:28:16AM -0400, Samael wrote:

{
configuration files from being exposed.

I hope I didn’t do anything stupid, I’m open to suggestions :slight_smile:

Edho, thank you for your advice, clearing the browser cache did the
trick, but still - I’d like to prevent that happening again by somehow
guarding the PHP scripts from being downloaded because of some
configuration error, for example.

Any “if ($uri ~* …)” construction means that it should
be replaced with “locaiton ~* …”.

As to regex locations I personally prefer to not use them at all
for several reasons, and to use only prefix locations, such as

location /download/ {
location /scripts/ {

I consider regex location usage only in legacy setups.
There are several ways to prevent execution of PHP in unexpected
places. 1st, the best one is to use prefix location:

location /scripts/ {
fastcgi_pass …
fastcgi_param SCRIPT_FILENAME /www/site$uri;
}

then anything such /images, /download, /upload will be hanlded in other
locations as static files.

If you have to use regex, then you can set SCRIPT_FILENAME to directory
separated from user uploadable content:

location ~ .php$ {
fastcgi_pass …
fastcgi_param SCRIPT_FILENAME /www/site/scripts$uri;
}

If /download, /upload, etc will be in /www/site/download/,
/www/site/upload, then it will be impossible to execute
/www/site/upload/hack.php, since nginx will use
/www/site/scripts/upload/hach.php instead.

The 3rd way, if you can not place scripts in separate directory, you
should proper order of regex locations:

location ~ ^/download {
root /www/site;
}

location ~ ^/upload {
root /www/site;
}

location ~ .php$ {
root /www/site;
}


Igor S.

Thanks for the suggestions, I will check how can I improve my
configuration upon them. Unfortunately, they seem to be less generic (ie
including specific paths) and so promote the probability of making
errors.

I’m wondering about the regex usage in location though - this is one of
the things I like very much about nginx. Can you please elaborate the
reasons for avoiding them?

Posted at Nginx Forum:

Igor, to cut things short - I’d like to either pass the PHP scripts’
execution to the fcgi processes or prevent them from being downloaded.

In addition, I tried to prevent PHP scripts in common
webserver-writeable directories (of course, this list will be extended)
from being executed in order not to allow user-provided PHP files to be
passed to php-fpm:

if ($uri ~*
/(images?|system|download|upload|cache|logs?)/(.*/)?[0-9a-z]+.php$)
{
return 404;
}

I set this rule: “location ~ /[0-9a-zA-Z]+.php$” in order to evaluate
only PHP files with alphanumeric names as these are the only one valid
from my perspective. Of course the rule may be improved (not allowing a
script beginning with a number to be evaluated), but I don’t think that
this is necessary at this point.

“location ~ (/.|.conf..php)” - in order to prevent hidden and
configuration files from being exposed.

I hope I didn’t do anything stupid, I’m open to suggestions :slight_smile:

Edho, thank you for your advice, clearing the browser cache did the
trick, but still - I’d like to prevent that happening again by somehow
guarding the PHP scripts from being downloaded because of some
configuration error, for example.

Posted at Nginx Forum:

Thank you for your advices and your insight, Igor, I’ve adjusted my
configuration file accordingly, feels much better now. It is stupid, but
the truth is that I didn’t know that it was possible to use nested
locations.

Спасибо!

Posted at Nginx Forum:

On Thu, Aug 04, 2011 at 04:33:30AM -0400, Samael wrote:

Thanks for the suggestions, I will check how can I improve my
configuration upon them. Unfortunately, they seem to be less generic (ie
including specific paths) and so promote the probability of making
errors.

I’m wondering about the regex usage in location though - this is one of
the things I like very much about nginx. Can you please elaborate the
reasons for avoiding them?

The difference is how nginx processes location.

If you use only prefix or exact locations, then nginx looks up
the longest match nevertheless of order of locations in configuration
file.
This allows you to have hundreds or thousands locations without worrying
how a new location will affect the existant configuration.

Regex locations depend on order, so during adding a new location
you have to look though whole configuration to see if the new location
will affect it.

A man thinks usually that he creates a small configuration with regexes
and it will work always fine. But configuration usually grows eventually
and at some point it become a difficult task to add new locations.

Rewrite rules aggravate this more.


Igor S.

12.08.2011, 11:28, “Samael” [email protected] ():

Thank you for your advices and your insight, Igor, I’ve adjusted my
configuration file accordingly, feels much better now. It is stupid, but
the truth is that I didn’t know that it was possible to use nested
locations.

!

We are working on comprehensive English documentation, including user
guides and reference.


Igor S.

On 2011年08月14日 12:25, Samael wrote:

nginx Info Page
Good,it will help many people.


Best regards,
Sharl.Jimh.Tsin (From China Obviously Taiwan INCLUDED)

Using Gmail? Please read this important notice:
http://www.fsf.org/campaigns/jstrap/gmail?10073.

Well, fortunately, I can read Russian pretty much without problems as I
studied it for years :slight_smile:

I could even help with the translation, if I may.

Posted at Nginx Forum: