Fastcgi & index

Server NGINX
#1

I’ve found that if I don’t specify:

index index.html index.htm index.php;

in the server blocks where I use fastcgi, I can get a 403 due to the
forbidden directory index. I would have thought ‘fastcgi_index
index.php;’ would take care of that. If this is the expected
behavior, should the index directive be added to the fastcgi wiki?

http://wiki.nginx.org/HttpFastcgiModule

  • Grant
#2

Hello!

On Wed, Feb 12, 2014 at 03:23:05PM -0800, Grant wrote:

I’ve found that if I don’t specify:

index index.html index.htm index.php;

in the server blocks where I use fastcgi, I can get a 403 due to the
forbidden directory index. I would have thought ‘fastcgi_index
index.php;’ would take care of that. If this is the expected
behavior, should the index directive be added to the fastcgi wiki?

This is the expected and documented behaviour.

The “fastcgi_index” directive is to instruct a fastcgi backend
which file to use if a request with an URI ending with “/” is
passed to the backend. That is, it makes sense in a configuration
like this:

location / {
    fastcgi_pass  localhost:9000;
    fastcgi_index index.php;
    include       fastcgi.conf;
}

It doesn’t make sense in configurations with only *.php file
passed to fastcgi backends though. E.g., in a configuration like
this it doesn’t make sense and should be removed:

location ~ \.php$ {
    fastcgi_pass  localhost:9000;
    # wrong: fastcgi_index doesn't make sense here
    fastcgi_index index.php;
    include       fastcgi.conf;
}

In this case, normal index processing applies. It is explained in
details in an introduction article here:

http://nginx.org/en/docs/http/request_processing.html#simple_php_site_configuration

–
Maxim D.
http://nginx.org/

#3

This type of configuration is insecure since there’s no whitelisting of
the
PHP scripts to be processed.

----appa

#4

No I mean the .php regex based one.

It’s just that it opens the door to a lot of problems by allowing all
.php
scripts to be
processed.

Furthermore it’s even mentioned on the wiki Pitfalls page:
http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP

----appa

#5

It doesn’t make sense in configurations with only *.php file
passed to fastcgi backends though. E.g., in a configuration like
this it doesn’t make sense and should be removed:

location ~ \.php$ {
    fastcgi_pass  localhost:9000;
    # wrong: fastcgi_index doesn't make sense here
    fastcgi_index index.php;
    include       fastcgi.conf;
}

In that case, should it be removed from the example here:

http://wiki.nginx.org/PHPFcgiExample

  • Grant
#6

Hello!

On Thu, Feb 13, 2014 at 02:09:34PM +0100, António P. P. Almeida wrote:

This type of configuration is insecure since there’s no whitelisting of the
PHP scripts to be processed.

You mean “location / { fastcgi_pass … }”? This type of
configuration assumes that any files under “/” are php scripts,
and it’s ok to execute them.

Obviously it won’t be secure if you allow utrusted parties to put
files there. But the problem is what you allow, not the
configuration per se.

–
Maxim D.
http://nginx.org/

#7

Trivial and correct fix for the problem mentioned on the wiki is
to properly configure php, with cgi.fix_pathinfo=0.

I would also recommend not allowing php at all under the locations
where you allow untrusted parties to put files - or, rather, only
allow php under locations where are untrusted parties are not
allowed to put files, by properly isolating .php$ location.

But again, there is nothing wrong with the configuration per se.

Is the example from the wiki a good one to use?

location ~ [^/].php(/|$) {

http://wiki.nginx.org/PHPFcgiExample

  • Grant
#8

Hello!

On Thu, Feb 13, 2014 at 02:47:35PM +0100, António P. P. Almeida wrote:

No I mean the .php regex based one.

So now you probably know why top-posting is discouraged. :wink:

It’s just that it opens the door to a lot of problems by allowing all .php
scripts to be
processed.

Furthermore it’s even mentioned on the wiki Pitfalls page:
http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP

Trivial and correct fix for the problem mentioned on the wiki is
to properly configure php, with cgi.fix_pathinfo=0.

I would also recommend not allowing php at all under the locations
where you allow untrusted parties to put files - or, rather, only
allow php under locations where are untrusted parties are not
allowed to put files, by properly isolating .php$ location.

But again, there is nothing wrong with the configuration per se.

–
Maxim D.
http://nginx.org/

#9

Trivial and correct fix for the problem mentioned on the wiki is
to properly configure php, with cgi.fix_pathinfo=0.

I didn’t realize the PHP config should be changed for nginx. Are
there other important changes to make besides ‘cgi.fix_pathinfo=0’?

  • Grant
#10

Hello!

On Thu, Feb 13, 2014 at 06:12:58AM -0800, Grant wrote:

In that case, should it be removed from the example here:

http://wiki.nginx.org/PHPFcgiExample

Yes, feel free to do so.

–
Maxim D.
http://nginx.org/