Understanding the Role of File Permissions in Website Security

Often in discussions of website security or hackings the issue of file permissions comes up. Unfortunately, important information needed to understand what effect permissions have is often not explained and in many cases bad information is spread. Most of the bad information relates to limiting other’s access to the files in your account on a shared server.

First let’s explain the basics of what file permissions are made of. In Unix based operating systems, which is what most web servers are running on, file permissions are composed three type of permissions: read, write, and execute. The read permissions allow reading the file, the write permissions allows modifying the file, and the execute permissions allow a file to run (because of how PHP works .php files do not need to be executed to run).

Directories also have the same types of permissions, but they are somewhat different. The read permissions allows see a listing of the files in the directory, the write permission allows creating, deleting, or renaming files in the directory, and the execute permissions allows accessing the files in the directory.

Those types of permissions are set for three different classes: the owner, group, and others. The owner is normally the user that created the file, the group is whatever groups the owner is part of, and other involves any other users on the system.

The first important thing to understand in terms of security is how the files can be accessed in the first place, because for permissions to come into play the hacker first has to be able to access the files. This requires having login access to the server, a FTP login for example, or having found some exploit in software running on the server. Just by browsing the website they could not access the files. If the hackers gains login access to your account or exploits software on your website they will have the same access that you have, so restricting others access will have stop someone from accessing your files in those cases.

We sometimes see it suggested that to protect a website that is being repeatedly hacked in a way that modifies files, that the write permissions for the files should be removed. The idea is that because the write permissions are disabled the hacker would no longer be able to modify the files. The problem is that most instances the hacker would have the ability to change the permission so that the files are writeable again. For almost as long as we have been seeing it be advised to make the files unwriteable we have been seeing hacks in which the permissions set to be writeable during the hack, so this is not effective strategy. What needs to be done is determine how the hacker is gaining access to the files and stop that.

The most important thing to understand about file permissions is that on a shared server, no matter what the file permissions are set to other users should not have access to your files. One of the developers of WordPress put it this way:

A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.

If your hosting provider does not have proper access controls in place the need to add those or your need to find a new host.

While setting permissions as low as possible is not going to do any harm, in most cases where the file permissions are blamed it would not have mattered what the permissions were set as. This is due the fact the files were being accessed in way that file permissions would not have restricted access. For example, a recent hack involved exploiting the web server instead of individual websites. Once the hacker gained access to the server they had access to all of the files on the server.

This entry was posted in Bad Security, Website Security. Bookmark the permalink.

Leave a Reply

one + four =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>