Users of the ITS Web Application Hosting service may find the following tips useful in order to prevent their web applications and data from being compromised by an attacker. As your application or site is hosted on a shared server and uses a networked filesystem (AFS), a compromise of your site could also negatively affect others on campus.
Understand requirements for secure application coding and hosting
All persons who develop, maintain, or host applications that process university data classified as Restricted, High, or Moderate should understand the requirements of Secure Coding and Application Security (DS-18). Information Assurance (IA) provides Secure Coding & Application Security guidelines and resources that can help you with protecting yourself and U-M. They include:
- Best Practices for Secure Coding and app hosting.
- Secure Coding Guidance and Training Resources recommended by IA.
- U-M App Security Testing Services you can use to help you check for application security.
If you use AFS to host your applications or websites, it is important to understand permissions. Having insecure or overly permissive file system Access Control Lists (ACLs) can lead to your website and data being compromised by an attacker.
Information on managing ACLs is available at:
- Managing Access to AFS Group Directories for websites
- Using Your AFS Home Directory Over the Web with MFile: Setting Folder Permissions
- Using Access Control Lists (ACLs) With AFS Directories and Folders
There are several things you should check for each directory:
Does system:anyuser or system:authuser have write access to this directory?
If either system:anyuser or system:authuser has write access to any directory, an attacker can modify your website by using either https://mfile.umich.edu/ or via AFS directly. The full list of dangerous rights includes: i, d, w, k, and a.
Instead of granting permissions to system:anyuser or system:authuser, use a PTS group as described in the ITS documentation noted above, and set the rights for both system:anyuser and system:authuser to "none".
Does system:anyuser or system:authuser have read access to this directory?
(if the website contains .htaccess files, web applications, scripting, or dynamic content or code)
If either system:anyuser or system:authuser has read access to a directory, an attacker can read any of the files stored there, including any private personal data, passwords, or other secrets. They can also read any code to determine how it works, what it allows, and how it can be attacked and compromised. While it is safe to allow system:anyuser or system:authuser read access if a website contains nothing but static HTML files, rights for both of these should be set to "none" if the website contains any web applications, scripting, dynamic content, code, or .htaccess files.
Does umweb:servers have write access to this directory?
The PTS group umweb:servers is used to control what the web servers that serve your web application or site are allowed to do. The web servers need to have read access in order to serve your web application or site. However, giving the web servers write access to your directories inside your website can make it much easier for attackers to exploit other vulnerabilities and compromise your website.
Please keep any directories that your web application needs to write to above the top-level directory for your website—or, better, store all data your website needs to modify in a database—and remove the ability for umweb:servers to write to any directory within your website. If this is not possible, then contact email@example.com to have scripting and other active content turned off for any directories that your web application needs to write to.
If you have any questions about web hosting, please contact the ITS Web/Database Team at firstname.lastname@example.org. If you have questions about sensitive data and secure app coding/hosting practices, contact Information Assurance through the ITS Service Center.