Writable Files and Directories Standard

Purpose

This standard defines Web Services’ practice with respect to writable files and directories on web servers.

Brief Description

To prevent malicious and unwanted content from being inserted into web sites on our web servers, writing files in web-accessible locations on the web server is prohibited to all customer-provided application code. Web Services will periodically audit and correct permissions that violate this standard.

Details

If web-accessible files can be written by interaction with visitors to a web site, all sites on the hosting server become vulnerable to attack. These attacks can take the form of (among others):

  • Denial of Service – filling a system’s disk, for example, with large files
  • Viruses and other malware
  • Distribution of “warez”
  • Inappropriate content
  • Site defacement

In addition to the security risks associated with writing files to web-accessible locations on the web server, there are also technical issues with multi-node clusters. Many of our shared infrastructure servers are now implemented as clusters of individual machines with a load balancer front end. When multiple nodes are providing the same content, it is imperative that the content on these nodes be identical. When web-accessible files can be written to the server, the ability to ensure this consistency is hampered.

For these reasons, writing files to web-accessible locations on the web server is prohibited to all customer-provided application code.

Maintaining the security and consistency of web sites on Purdue IT web servers is the joint responsibility of Web Services and developers. Web Services has developed periodic scanning jobs that look for and correct permissions of files and directories that have been set to be writable by the web server. While these jobs will prevent the long-term errant permission, it is possible that in the short term, a developer may think their code (that writes files) is working, only to have it suddenly fail when the scheduled job corrects the permissions a few minutes later. Therefore, developers need to ensure that they avoid activities that can inadvertently (or intentionally) create writable files and directories. This includes ensuring that file permission settings on the chosen file transfer application have appropriate values as well as not attempting to change the permissions on files or directories to make them “writable”.

When a web application must support uploading files to the web server, the following alternatives to writing web-accessible files exist:

  • Databases – Any of the supported database systems provided by Purdue IT can be used to store uploaded content. Because the contents of a database can only be provided to a visiting web browser under the control of application code, many of the above attacks can be mitigated (e.g. it is not possible to overwrite or alter an existing file on the web server) and since the database is shared by all cluster members, consistency of content is preserved.
  • DATA directories on Windows – On request, the DATA directory provided for each site can be made writable to the site’s application code. Windows provides mechanisms to prevent one site’s application code from writing to another site’s DATA directory as well as providing automated multi-way replication of content between cluster nodes. The DATA directories on our Windows systems are configured with this replication service and with appropriate security settings to isolate each site’s access. For a similar option on Linux servers, see the next bullet.
  • A departmental file share – On request, a departmental file share can be mounted to the DATA directory space of web sites on our Linux servers. This file share can then be written to by web site application code and provides a consistent view of the files stored there to all nodes in a cluster. It is also possible to use a departmental file share in our Windows-based environments, but the file share cannot be mounted by the system. Instead, it must be accessed directly by the site’s application code using a service account’s credentials embedded in the code. Note that using a file share does present a single point of failure to the web site.