PHP LFI fix with the right file permissions

Question

I'm trying to understand how to perform a LFI (specifically PHP LFI), and there is a aspect of this attack that seems to be never discussed in online articles I read: The injected file permissions.

Indeed, let's assume I can inject a file in the system. Most of the time, it is not gonna be word readable or executable (even the directory might not be traversable). Therefore, even if I can traverse a path though a ?file=../../../../../shell.php, it won't get executed.

What I'm trying to say is that, according to me, if a system running PHP is well configured and assign the right permissions to files, there is no need to worry that much about files extensions, files content ... So instead of adding multiple checks on the file injected as suggested on multiple online resources, shouldn't the dev focus on the system configuration (allow_url_include=0, file permissions,...) ? For me, it is comparable to SQL injections. You would rather use prepare statements and simple user input checking than vulnerable queries and complex user input checking with huge whitelists/blacklists.

Am I missing something ?

Answer 1

I would consider these two different vulnerabilities: storing a file in the remote server and the local file inclusion, which would read/execute it. Each of them can be sufficiently bad on their own.

A LFI vulnerability typically allows you reading files to which you shouldn't had access. For instance, a path traversal vulnerability in a comment system could allow reading instead the configuration of the web application and allow access to keys used by the application (like the database credentials). You can't change the file permissions so that the web application can't read it, since the application needs reading it. It just shouldn't show the contents to the user.

Another typical case would be that the application allows uploading images, and you can then include the uploaded image as a php file. The file was created by the web application, so it will be the file owner and have access to the file (if the webapp runs under a different uid than your webserver, you could remove the read permission from the owner and leave it for others so that it can be shown to the user. Still, the application may nevertheless need to read the uploaded image later, such as for generating a thumbnail).

As for storing files, it should be clear that if you are able to upload a file in the right place (eg. a file with a script extension in a folder server by the web server), it could be executed without a LFI vulnerability.