Security Vulnerability: NGINX Configuration Allows Unrestricted Access to PHP Files in Specified Directories

[dharmeshmp]

Issue Description:

When the location ~* /(?:uploads|files)/.*\.php$ block is placed below the location ~ \.php(/|$) block in the NGINX configuration, it allows access to PHP files in the specified directories. Moving this block above the PHP location block resolves the issue.

Configuration:

server {
    listen {{NGINX_LISTEN_PORT}};
    server_name localhost;
    root {{NGINX_WEBROOT}};

    index index.php index.html index.htm;

    # Deny access to any files with a .php extension in the uploads directory
    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php(/|$) {
        include /etc/nginx/snippets/php-fpm.conf;
        fastcgi_split_path_info ^(.+?\.php)(/.+)$;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    include /etc/nginx/snippets/site_optimization.conf;
    include /etc/nginx/snippets/exploit_protection.conf;
}

Steps to Reproduce:

1. Configure NGINX with the provided configuration.
2. Attempt to access a PHP file in the /uploads or /files directory.
3. Observe that access is allowed when the location ~* /(?:uploads|files)/.*\.php$ block is below the PHP location block.

Expected Behavior:

Access to PHP files in the specified directories should be denied regardless of the order of the location blocks.

Actual Behavior:

When the location ~* /(?:uploads|files)/.*\.php$ block is placed below the PHP location block, it allows access to PHP files in the specified directories.

[tiredofit]

Hi there thank you for the report. Indeed this should be addressed.

Can you tell me where you are seeing this configuration file? It's not being auto generated in this project but more than likely in a downstream project that relies on this base. I can address that immediately.

[tiredofit]

I see that in the example in the README these directives are out of order. I have made adjustments to the example here c25ee33.

[dharmeshmp]

Thank you for the quick response and for addressing the issue in the README example.

In our case, we encountered the misplacement of the configuration directives in the NGINX configuration file "/etc/nginx/sites.enabled/default.conf" when using the "tiredofit/nginx-php-fpm:alpine-8.1" image. The misplacement led to a potential security vulnerability where access to PHP files in specific directories was not properly restricted.

As of now, we have manually adjusted the order of the directives in our configuration file to resolve the issue. However, it might be beneficial to update the base image or provide a clear note in the documentation about the correct order of these directives to prevent potential security risks for other users relying on the image.

Thank you for your attention to this matter, and please let me know if there's any additional information or testing I can assist with.

[tiredofit]

Thanks for the additional update. I too can see what you are talking about.

With tiredofit/nginx-php-fpm:alpine-8.1 it uses version 7.4.1 (2023-01-16) which contains the statement.

With tiredofit/nginx-php-fpm:8.1-alpine it uses the version 7.7.6 (2024-02-16) which doesn't.

I think at some point I changed the naming conventions around and this change may not have been communicated clearly. I also recall having a real set of problems with my automated builds recently and I have a feeling this was related.

So, if you wanted to shift your image being used you'll get the benefit of the directive actually not appearing in the configuration entirely, and updates all around with nginx, php and its associated dependencies, and some of the lower level alpine packages brought more up to date with whats available...

If you wanted to use your own configuration you could do the following:

Create a new image with this as the base image OR map some files when starting the container

• drop a configuration file in /etc/nginx/sites.avaialable/configname.conf
• Set the environment variable of NGINX_SITE_ENABLED=configname and it will use that as opposed to generating the default config.

A great example of this would be the tiredofit/wordpress image. https://github.com/tiredofit/docker-wordpress - I have a custom nginx configuration file that is being added, and in the Dockerfile am stating which configuration file to use, and also to not create default index.php files upon startup.

I hope this helps!

[dharmeshmp]

Thank you for the prompt response and for addressing the configuration issue. I appreciate your assistance.

I'm also interested in enhancing the security of my NGINX configuration and would like to inquire about the proper way to implement the following security measures:

server_tokens off;
more_clear_headers Server;
add_header Content-Security-Policy "default-src 'self'" always;
add_header X-Frame-Options "deny" always;
add_header X-Content-Type-Options "nosniff" always;
more_clear_headers X-Runtime;
more_clear_headers X-Powered-By;

Could you kindly provide guidance on how to incorporate these security steps into the NGINX configuration file properly? I want to ensure that these directives are implemented in a way that aligns with best practices and doesn't interfere with other aspects of the configuration.

Thank you again for your support, and I look forward to your guidance on this matter.