...
- Reduce the frequency of compromises. To the extent that we foster development of custom-written web applications, educate developers about these attacks and how to prevent them. For off-the shelf web applications, provide cookie-cutter installations, monitor security sites for known exploits, and have a framework for fixing the cookie-cutter installations users have performed.
- Reduce the severity of compromises. No matter what we do, user account compromises will be endemic to our service, so we need to provide good tools for recovering from attacks (frequent user-accessible backups, for example) and to ensure that attacks do not spread to other users of the service.
3. User boundaries
This is a complicated topic and is best considered in pieces. This is also an area where we are in conflict with the world of web hosting at large. Most commercial web services do not insulate users from one another, and most web application installation instructions only concern themselves with instructing users how to break down what barriers exist, not how to work within them.
3a. Static content
Public static content (e.g HTML files) is not an issue as long as it is only writable by users other than the owner. However, some number of users will naively set their static content to be group or other-writable. It may be necessary to protect such users against themselves.
Private static content (anything protected by a .htaccess file) must be readable by the apache user if httpd is going to be able to serve it normally. This means making those files world-readable, which is an issue if it allows other users to read the content without going through httpd access controls. If all users are placed within the same group, the files can be protected against other users by making them not group-readable--assuming users have no ability to read the content from the apache account using dynamic content featuerss (see below). Again, it may be necessary to protect users against themselves.
(Unfinished beyond this point)Wiki Markup