Limit the damage

No matter how diligent you are at preventing vulnerabilities and securing your environment, it's impossible to be completely secure on the Internet. What you can do is plan for how to limit the damage that people can do when they manage to compromise some part of your system. This line of thinking is called "Defense in depth" -- you can't just apply security updates and call it good.
One common attack on web applications is to find some vulnerable code that allows an attacker to upload some malicious bit of code to the server, and then they can execute it through their web browser. This gives them a login straight into the server, bypassing the usual ways of getting there. We have seen this attack succeed more often than you would think -- we've gained several clients by going in after the fact to clean up the damage.
When we're managing a Drupal site, we get around this by using operating system file ownership privileges to make sure that everywhere the web server can possibly create a file, that file cannot be run as a program. This limits the potential damage because when an attacker goes to upload a malicious file, they either get a permission denied to save it where it can be run, or they put it someplace harmless where hitting that location just returns the file to him instead of running it as a program. The worst the attacker can do becomes replacing some of your graphics files or replacing some optimized javascript -- which is a potential threat for your users, but far easier to detect and recover from than slipping in a program that runs on the server as a local user.
Other techniques include setting up "jails" for programs so that when they get broken into, they can't get to the rest of the system. These are the kinds of measures far beyond a typical web developer, and we've seen big developer shops who neglect to even have a reasonably strong password policy. What happens when an attacker gets this far? Read on to find out.