Guidelines for web site file and directory permissions

File and Directory Permissions for Web Sites

Help prevent the spread of intrusion from web-based attackers by setting proper file and directory permissions!

Goals

• Understand the importance of proper directory and file permissions.
• Understand the consequences of setting improper directory and file permissions.

Motivation

Web applications present an attack vector to a remote attacker who wishes to gain access to a web server. We can not prevent vulnerable or even malicious web applications from running on our servers, but we can try to limit the damage that results from one.

Concerns

All sorts of "bad" can come from an unauthorized user on a web server, however, we're primarially concerned with the following scenarios in this document:

• Site defacement.
• Use of site to host unauthorized content (spam, malware, work in violation of copyright, illegal adult content...).
• Use of site to successfully leverage attacks on other co-hosted sites.

Causes and Consequences

The fundamental problem here is that a web server has the ability to write to a directory under its document root, or another directory under some other web server's document root.

An attacker, using a vulnerability in a web application, can create or replace files and directories belonging to the same site. This level of access may result in the site being used to host unauthorized content, becoming defaced, or covertly modified to steal credentials. (How many of you use the same password in more than one place?)

The attacker may also try to create or replace files and directories belonging to a different site. This level of access is particularly troublesome because the attacker can compromise the different site that may not have a vulnerable web application. Furthermore, once the attacker has placed a backdoor on the victim site, they can access their backdoor through the victim site's web server process and assume a completely different user identity, which may yield additional levels of access not available to the user running the first web server process.

If the attacker does not already have the ability to do so, this sort of "hopping" may eventually yield the ability to compromise other sites or even access data that would not normally be available over the web.

Prevention

Use the following guidelines when setting and auditing permissions in your site's document root. They eliminate or limit the areas a web server can write to -- decreasing the places to perform a defacement or place unauthorized content. These guidelines also help prevent situations where the web server can be used to "program itself" by using a vulnerable web app to create a script that the server will later be used to run.

1. All directories and files under the document root must not be world-writable. No exceptions!
2. All directories under the document root must not be owned by any web server user. No exceptions!
3. All files under the document root should not be owned by any web server user. See "Server-generated content" below for exceptions.
4. All directories and files under the document root should not be group writeable if the owning group contains any web server user. See "Server-generated content" below for exceptions.

Server-generated content

Some web applications require the ability to generate content under their site's document root, for example, the page cache in a CMS. In these instances, the web site's administrator must set, at the lowest level of the directory tree (farthest from the document root), all of the following:

1. The directory must be writeable by the web server's group.
2. The directory (and descendants) must prohibit the execution of CGI, server-side includes, and PHP. A .htaccess file with the necessary configuration options may be used for this purpose. (or set these options in the httpd server configuration file)
3. The directory must have it's sticky bit set (chmod o+t)
4. The .htaccess file, if used to disable the above features, must not be owned nor writeable by the web server. (This usually means rw-r--r-- permissions). If an .htaccess file is not used, the httpd configuration file must be used instead.

As an example say a web application needs to write to /www.example.com/www/data/cache. The site's administrator must apply the above controls to the lowest level possible -- /www.example.com/www/data/cache. Applying the above controls to higher levels such as /www.example.com/www/ and /www.example.com/www/data/ to satisfy the application's requirement to write to /www.example.com/www/data/cache will not meet the above guidelines.