While an entire volume could be filled with common mistakes, we'll focus on a few of them here. They are presented here in no particular order.
One big problem comes in if you are using a component that is vulnerable. To start with, why would we deliberately set up our site to be broken into? A quick review of the current vulnerability list shows at the time of writing of over sixty known vulnerable extensions.
Here is one chosen at random known as AutoStand. I followed the link listed in Joomla! and found the security site FrSIRT. They list this as a critical exploit.
Advisory ID : FrSIRT/ADV-2007-1392
CVE ID : CVE-2007-2319
Rated as : High Risk Remotely Exploitable : Yes
Locally Exploitable : Yes
Release Date : 2007-04-16
A vulnerability has been identified in AutoStand (module for Joomla), which could be exploited by remote attackers to execute arbitrary commands. This issue is caused by an input validation error in the "mod_as_category.php" script that does not validate the "mosConfig_absolute_path" parameter, which could be exploited by remote attackers to include malicious PHP scripts and execute arbitrary commands with the privileges of the web server.
Affected Products:
AutoStand (module for Joomla) version 1.1 and prior
Solution:
The FrSIRT is not aware of any official supplied patch for this issue.
References:
http://www.frsirt.com/english/advisories/2007/1392
According to this alert, Autostand version 1.1. and prior is vulnerable, and this advisory mentions that at the time of writing there was not a fix. To be fair, by the time this book comes to print, it is likely that it will have been taken care of. What is important is that we can see there is a highly critical vulnerability (see frsirt.com advisory for severity level). The actual nature of this attack is input validation, meaning, the programmer for this particular version did not properly sanitize the user's input. If I were "Johnny Craxbox" the kiddie script guy from somewhere in the world, I might pass arbitrary commands to the system such as the following:
rm -rf *
Whether this would work or not is unknown, but please do not try it, and it's most likely that it will be unknown to the cracker. But if it did pass through with the privileges of the web server, then I have instructed the server in the last part to delete the entire web document tree. Not a good thing to say the least. These vulnerabilities are almost always known to the bad guys before they are known by the good guys, or even the author of the application. Checking the third-party vulnerability list is not only easy and quick, it's simply a very good idea. To fail to check the list is tantamount to laziness. Take off a few minutes right now and bookmark this location:
Note
Tip to check the third-party Vulnerability list from Joomla.org.
http://help.joomla.org/component/option,com_easyfaq/task,view/id,186/Itemid,268/
As discussed earlier, having Register Globals enabled is a huge problem. This is so prevalent that a search on the Joomla! forums will turn up multiple instances of this repeated offense.
Seeing 777 may be lucky if you're in Las Vegas, but it's hell to pay on your site. We discussed the correct permissions settings earlier, but it bears mentioning them here again. If you have made all your directories and files 777, then get a backup, sit back, and wait to start your restore.
While this may be a bit out of the scope with this book, writing down your database settings can be invaluable in an emergency situation. If you are cracked, you may need to reference the authentication information quickly. Write it down! Store it in a safe place.
Surprisingly few people have backups much less practice backing up, preparing a plan, or testing the plan. DO NOT let this simple action keep you from doing it. Back up.
There are several ways to go about backing up. You have to choose the method that works best for you, but whatever method you choose, it must have the following elements in it:
Ability to capture directory structures, files, permissions, and database.
Ability to lay your hands on it quickly.
It must work when restoring is needed.
It must be fresh and up-to-date.
Establish a multi-session backup scheme. You should have three to four weekly rolling backups. That way if you were cracked in week two of the month, but you know week one is good, you have that copy.
You need a standard enumeration method (fancy word for naming) for your backups.
You should practice restoring a few times to make sure you have it.
If you do these simple things you are going to be way ahead of the pack.
Note
Disaster Recovery and Business Continuity
This topic is beyond the scope of this book. However, one key question to ask your prospective host, shared, dedicated or co-location is, "Who does the backups?", "How can you get them restored?", and "What is the cost and time to restore?". You will be shocked to learn that in quite a few cases you will be expected to back up your own data and take it off site. For a more detailed discussion of this topic, the reader is encouraged to read the author's disaster recovery book: Dodging the Bullets, a Disaster Preparation Guide for Joomla! Web Sites. Or take the time to research and set up a good, solid back up, and recovery plan.