Installation Security

As with any dynamically-generated website that allows user input, there are a number of security concerns that need to be addressed to secure your server from malicious attackers.

This document does not purport to be a comprehensive guide to server security, but it will attempt to outline concerns relevant to Manifesto, and the methods employed to counteract possible breaches in security.

Apache security

Aside from general concerns about web server security, you need to know a few things about how Manifesto works, what its file structure is, and how this might affect your Apache configuration.

Permissions

First, the user under which Apache runs (the "User" in httpd.conf, usually "apache" or "nobody" or "www") needs to have write access to most of the files on your site. While certain directories absolutely must be writeable by Apache (/usermedia/, /cache/), most other directories should also be writeable so that you may employ the Auto-Update module to keep your site up-to-date. Essentially, you want your user account and Apache's user account to be able to manipulate files on your site.

For example, if your personal shell account is under the user "imcuser," you probably want your files to be owned by "imcuser" so that you may read/write/update/FTP them without issues. Since Apache is not likely to be running as the "imcuser" account, you must grant Apache write permissions by making the group ownership of the files belong to some group account that includes Apache's user as a member. So if your files are owned by "imcuser/wwwgroup", then Apache's user account must belong to the "wwwgroup" group.

Here's an example:

• Your account is imcuser. You also belong to a group with the same name, imcuser.
• Apache runs under the user account www. The www user also belongs to a group called wwwgroup.

Given this scenerio, you have two choices for setting file permissions:

• Set files to be owned by imcuser/wwwgroup, and set their permissions to 664 (-rw-rw-r--).
• Set folders to be owned by imcuser/wwwgroup, and set their permissions to 2775 (drwxrwsr-x). The extra "2" in front of the permissions essentially tells Apache that new sub-folders should inherit the same permissions.

The other option -- if you have this much control over your server -- is to add the www user to the group imcuser. This makes Apache run as part of "your" group, and allows it to access your files. In this case, you need to:

• Set files to be owned by imcuser/imcuser, and set their permissions to 664 (-rw-rw-r--).
• Set folders to be owned by imcuser/imcuser , and set their permissions to 2775 (drwxrwsr-x). The extra "2" in front of the permissions essentially tells Apache that new sub-folders should inherit the same permissions.

Restricted Directories

Apache will serve almost any kind of text file that is requested, so you might want to prevent certain types of file from being served on your site.

For example, the default location for the dadaphp.log file is in the /logs/ directory of your site. With no protection, a user requesting http://www.example.com/logs/dadaphp.log can view your error log file. You almost certainly don't want this. To prevent Apache from ever serving files from your /logs/ directory, add this to your VirtualHost directive:

<Directory /full/path/to/logs/>
  Order Deny,Allow
  Deny from all
</Directory>

Similarly, you may want to prevent access to your /docs/ directory, since nothing in there needs to be publicly visible:

<Directory /full/path/to/docs/>
  Order Deny,Allow
  Deny from all
</Directory>

Any file containing privileged information, e.g. the dt_dbinfo.php file, is configured as a PHP file so that, if requested, it returns only a blank document, and does not reveal any of the PHP variables stored in the script. Nonetheless, many other files used as included scripts on the site are configured with the suffix .inc. Apache will serve these files as raw code if requested, though no sensitive information is transmitted -- the user will simply see the layout HTML and the PHP code used to display the page contents. If you wish to prevent anyone from seeing even this much information, add

<FilesMatch "\.inc">
 Order allow,deny
 Deny from all
</FilesMatch>

to your VirtualHost configuration (or .htaccess file).

Text input by users

Manifesto uses a cleantext() function to "scrub" user input before displaying it or sending it to the database. This routine removes potentially malicious code fragments from all user input, stripping out javascript, meta tags, iframes, object and applet tags, etc. In addition, Manifesto checks the form of input, so that, for example, a script that expects a parameter to be an integer will reject any parameter that does not conform to the expected type.

File uploads

This is the most dangerous form of user input, since Manifesto allows for such a broad variety of uploaded file formats. Since it is quite easy to "spoof" file types (for example, uploading a text file with the suffix .jpg to trick the server into thinking that it is an image file), Manifesto performs a number of extremely strict checks before permitting file uploads. The sequence is something like this:

1. Check for standard PHP file upload errors. If none are detected, proceed.
2. Grab the suffix of the uploaded file. For a successful file upload, the file must have an appropriate file suffix.
3. Check the file suffix against the internal blacklist or whitelist, depending on which method is set in the preferences. The whitelist permits only a limited list of suffixes, while the blacklist is more permissive, and only rejects a limited list of suffixes. If the suffix is permitted by your settings, continue.
4. Determine the MIME type of the uploaded file, using the PHP mime_content_type() function.
5. Compare the MIME type result and the file suffix. Look in the Manifesto mimetypes table for an entry that describes both the returned MIME type and lists the returned suffix as a valid extension for that MIME type. If there is no match, reject the file.
6. If the uploaded file appears to be some form of text file, run it through the cleantext() function before permitting it.

All of this results in quite secure -- if picky -- handling of uploaded files.