Writeable Directories for the Web Server: Risks and Protective Measures

Normally, the web server is only allowed to read files and directories in the webspace. For some web applications, e.g. blogs or file uploads, it may be necessary to allow the web server write access to a directory. This involves substantial risks for which there are only partial technical means of protection.

Such risks are for example:

Stored files may contain malware (e.g. viruses).
In principle, any program running on the web server can write data to this directory (or delete and modify if rights are present). This can happen unintentionally, for example, but also deliberately through malware.
If stored "hacker scripts" (PHP or CGI) are executed by the web server, further damage can occur (e.g. data manipulation, installation of data protection-violating JavaScript in HTML files).

Since the web space of the central web servers is located in the AFS file system, special conditions apply here:

Assigned permissions are granted per directory and then apply to all files in this directory.
Newly created subdirectories "inherit" the rights of the parent directory. This means that if you create further directories in a directory that is writable for the web server, in turn these directories will be writable if you do not adjust the rights subsequently.
Unix rights play (almost) no role.
To set the access rights, see Access protection to web documents in the AFS file system

As a web author, you have a great responsibility with such writeable directories:

Planning: What authorisation is required in the file system, what access protection is to be set for the web server?
Risk assessment: Despite technical measures, a residual risk often remains. Another solution may have to be found for sensitive data.
Correct setting of permissions
Registration of the writeable directory:
- In order to exclude erroneously assigned rights, the write permissions in the web space are checked daily.
- For unregistered directories with write permission, the permissions are reset to "Read only".
Regular and frequent checks of the permissions for your directories in the web space and the files that are in a writeable directory.

We are happy to help you with all these points: Contact us by e-mail at webmaster@….

The following overview shows usage examples and risks as well as protective measures for writeable directories. It is irrelevant whether the corresponding web application or upload script is only available to a few people or is public.

1. Files in the Upload Directory Cannot be Read Via the Web.

Examples of use:	Writing log files Submitting papers for conferences for review
Risk of misuse without protection:	low Files are "fetched" by authorised persons via the file system. These must be checked for viruses.
AFS rights for the Upload directory:	Upload directory should be outside the web space, e.g. in a project directory. Files may only be created, but not read or modified: List / Enter + New files `ip:www-server li` Existing files may only be modified (often does not work with PHP): List / Enter + Change, no read, no new files, no delete `ip:www-server lw` Files may be created and modified: List / Enter + Change + New files, no read, no delete `ip:www-server liw`
Settings `.htaccess` in the upload directory:	none, as web server is not allowed to read. For double security: `# Prevent direct access to all files Require all denied`
Remaining risk:	Uploaded files may contain malware → Use virus checker.

2. Files in the Upload Directory Can Only be Read on the Web to a Limited Extent (Authorised Users).

Examples of use:	Exchange of files in closed user group (without peer review)
Risk of misuse without protection:	high for those authorised to access, esp. danger from scripts (PHP, CGI) with malicious code (e.g. for data manipulation) introduced by third parties. Files may contain malware.
AFS rights for the upload directory:	Only set the rights that are absolutely necessary. The risk increases the more rights are set: Files may only be modified and read: Read + Change, no delete, no new files `ip:www-server rlw` Files may only be created and read: Read + New files, no change, no delete `ip:www-server rli` Files may be additionally modified: Read + Change + New files, no reading `ip:www-server rliw` Files may be additionally deleted: Read + Change + New files + Delete `ip:www-server rlidw`
Settings `.htaccess` in the upload directory:	also see settings of the access control. `# Setting access rights, e.g. AuthType shibboleth ShibRequestSetting requireSession 1 Require shib-attr idmgroup urz:chemistry_students # Prevent execution of PHP php_flag engine off # Switch off: cgi, SSI, listing of contents Options -ExecCGI -Includes -Indexes # Only .pdf and .doc files allowed Require all denied <Files ~ ".+\.(pdf\|doc)$"> Require all granted </Files>`
Residual risk:	Uploaded files may contain malware → Use virus checker. HTML files can contain malicious code (JavaScript).

3. Files in the Upload Directory are Publicly Readable on the Web.

Examples of use:	Upload documents and images that are immediately visible to all. To avoid providing a public uncontrolled data exchange space, the upload script must absolutely be provided with access protection (but this alone is not sufficient)!
Risk of misuse Without protection:	very high Damage to reputation due to files with corresponding content brought in by third parties Danger from scripts (PHP, CGI) with malicious code (e.g. for data manipulation) introduced by third parties. Files may contain malware.
AFS rights for the Upload directory:	Only set the rights that are absolutely necessary. The risk increases the more rights are set: Files may only be modified and read: Read + Change, no delete, no new files `ip:www-server rlw` Files may only be created and read: Read + New files, no change, no delete `ip:www-server rli` Files may be additionally modified: Read + Change + New files, no reading `ip:www-server rliw` Files may be additionally deleted: Read + Change + New Files + Delete `ip:www-server rlidw`
Settingy `.htaccess` in the upload directory:	`# Prevent execution of PHP php_flag engine off # Switch off: cgi, SSI, listing of contents Options -ExecCGI -Includes -Indexes # Prevent delivery of .php, .php3 and .cgi files <Files ~ "\.(php3?\|cgi)$"> Require all denied </Files> # Only image files: .jpg, .png, *.gif are allowed, # all others are not readable Require all denied <Files ~ ".+\.(jpg\|png\|gif)$"> Require all granted </Files>`
Residual risk:	Uploaded files may contain malware. Since everyone can read the files, the distribution is uncontrollable. HTML files can contain malicious code (JavaScript). As a result, entire areas of the web server can be blocked.

4. Software for Web Applications Requires Write Permissions

If one uses a software product for a web application, e.g. for a web survey or a content management system, then these packages often have requirements that certain directories must be writable. What are the options here?

4.1. A Few Defined Directories

e.g. for temporary files, cache or upload
Check if one of the above scenarios applies, set appropriate access rights (AFS, .htaccess), register the directories accordingly.
If none of the scenarios fits → 4.2

4.2 Many or Indeterminable Directory Hierarchies

e.g. for the automatic update or import of plug-ins
This software is not suitable for operation on the central web servers, because the security risk is too high!
For this purpose we recommend the operation of an own virtual server.

So you see here too that security has its price – the configuration is quite complex. That is why we are happy to advise you in the planning of your web projects. On the other hand, a subsequent modification of existing projects to increase security is usually very difficult and time-consuming.

By the way: If you need an upload capability for your HOME directory (or for other directories for which you have write permission), you can use a ready-made solution: Use the web-based file manager WFM of the login server: https://wfm.hrz.tu-chemnitz.de/wfm/