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.
Stay up-to-date on any security announcements for web applications which you have installed by joining the appropriate mailing lists and keeping current with the latest versions of the software.
Files which contain personally identifiable information (PII) or other sensitive data should not be stored in your website's directories, unless protected by both authentication (such as cosign) and authorization (such as LDAP group membership requirements). Unprotected data can be retrieved by attackers who guess the file's URL. Consider storing private or sensitive data in a database or above the top-level directory of your website. In addition to passwords and keys, refer to the Sensitive Data Guide for types of personally identifiable information (PII) that must be protected.
Any files that are uploaded by your web application should be stored in a database or outside of the top-level directory for your website, if possible. Special web pages can be set up to allow these files to be downloaded by other users; contact email@example.com for more information. If it is not possible to configure your web application to store uploaded files in a database or above your website's top level directory, then it is imperative that all scripting and other active content be turned off for the upload directory; contact firstname.lastname@example.org to have this done for your website's upload directories.
Note: A common way for an attacker to compromise a website is to upload a file containing malicious content in the language used by your web application — if your web application stores the uploaded file underneath your website's top-level directory, then the attacker can handcraft a URL to access their uploaded file directly, causing their malicious content to be run and giving them control of the website and web server.
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 http://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.
Before you write code for your site, spend some time up front to make sure it is designed to be secure.
Before deploying code you have written for your site, audit it to be sure it is secure, or consider asking a security professional to review it for you. For assistance in finding a security professional, try contacting Safe Computing or University Audits.
The Open Web Application Security Project (OWASP) is an excellent resource for learning more about web-related security vulnerabilities and how you can protect your users, applications, and data. A good starting point is the OWASP "Top Ten" list.
Top concerns include:
- Properly validating input — only accept exactly what you expect.
- Properly encoding/escaping data — make sure content you serve that comes from one user can't do something bad to other users.
- SQL injection attacks.
- Cross Site Scripting (XSS) attacks.
- Cross Site Request Forgery (CSRF) attacks.
ITS offers an intrusion prevention system for PHP web applications known as Suhosin that can stop many attacks before they reach your web application's code. (Note that Suhosin is not a substitute for writing and configuring web applications to be secure; it merely provides an additional layer of protection to improve the odds of withstanding an attack.) If your site uses PHP and you'd like to have your web application moved to a server that is protected by Suhosin, please contact firstname.lastname@example.org to get started. Plan on some work needing to be done by your web development staff to get your web application under Suhosin's protection, though, as Suhosin's strict security can cause problems with some web applications.
Eventually all web applications and sites that use PHP will be on servers that use Suhosin.
We suggest doing the following once each semester in order to stay neat and clean:
Know your files
Inspect all of the files that make up your web application or site to identify any which should not be there or are suspicious. Also take this opportunity to review the filesystem ACLs on each directory in your website.
Change your passwords
If your web application uses any passwords (for example, database passwords) or private keys, change them regularly. See ITS Documentation for instructions on how to change passwords for MySQL and Oracle databases.
Delete old code
If you have parts of your website that are no longer used, delete them. Old, unmaintained code is an easy route in for attackers.
Be sure to remove staff members, students, or other users who are no longer with you from:
- PTS groups that control access to your website's files in AFS
- AFS Access Control Lists
- LDAP groups that your website uses for authorization
- .htaccess files
- User tables or authorization tables in your database
Review or audit your code
Once a year, do a code review of any code you have written in-house to see if it has any security problems. Pay particular attention to problems on the OWASP "Top Ten" list as well as any new security vulnerabilities that have been in the news recently.
Consider having a security professional audit your web application or site's architecture as well as its code every other year.
If you have any questions, please contact the ITS Web/Database Team at email@example.com.