File Permissions for Web Servers

June 21st, 2016

Many of you have asked me to write an article about Unix file permissions for web servers. This will serve to combat all those recommendations that are floating around, such as chmod -R 777, which I like to call the "hacker's jackpot."

Basics of File Permissions

The first concept to understand is the three roles. The user has the highest access to a file or folder; the group is more limited. With your hosting, you would often see the group www-data or apache, which is the group under which the web server is running. It will, for example, allow your scripts to move uploaded files, create the application cache, or write log files. The other role is the most open. It means that anyone in the system has access. This is particularly dangerous with shared hosting.

The second concept is the three permissions: read, write, and execute. The first two are self-evident, while execute should be reserved for console commands.

Attacks

Here are a few attack examples and ways to prevent them. (Sadly, there are too many to list them all.)

Executable uploads. Someone can upload a file that seems to be a profile picture, but instead, it's a malicious script that contains everything the hacker needs to navigate your directories, access the database, etc. All the hacker needs to do is to navigate to the image's location in the browser and they get a neat console. Make sure that you don't allow execution within upload folders. You can also set your web server configuration to prevent scripts like PHP from being interpreted.

Shared hosting access. If you give other permissions, then it's possible for other users to cross boundaries and access your files. It's also possible for someone to gain access to the server by other means – not necessarily through hosting – and then get to your files.

Directory traversal. If your folder has the execute permission for other, then it can be traversed by any user on the system. This allows hackers to discover your structure, to learn what apps you use for later exploiting of vulnerabilities, to find the location of configuration files for including them in plain-text from other scripts, and to find vulnerable files or scripts that may have been left on the server (like Adminer).

The dangers of someone accessing your files include reading your configuration files with passwords, appending malicious code in your application files to serve them to your users, and executing undesirable commands on the server itself.

Setting Permissions

You don't have to bother with the numeric permissions such as 777 if you find them too complicated. You can grant and revoke specific permissions quite easily.

For example:

chmod g+w filename – This will grant the group permission to write to that file. Useful when your application complains that your cache folder is not writeable.

chmod o-x filename – This will revoke the execute permission from other. There is probably no reason for any of your files to be executable by other. As a matter of fact, there is very little reason to grant any permissions to other in your website directory. Only you and your web server, such as Apache or Nginx, should have access to these files. Don't let strangers snoop around!

Permission Checklist

Nic has a nice little checklist:

• Developers need read/write access to files so they can update the website.
• Developers need read/write/execute on directories so they can browse around.
• Apache needs read access to files and interpreted scripts.
• Apache needs read/execute access to servable directories.
• Apache needs read/write/execute access to directories for uploaded content.

Let hackers beware. You’re in control.

Previous: We are all biased Next: MySQL Duplicate Entry, But Not Really