I’m doing some work for a client who has a number of Joomla-based websites, and he’d been hacked. My usual tricks for figuring out the vector of attack failed me (the site had already been cleaned up by another firm, who may have disturbed my crime scene,) so all I was left with was the usual “find what holes I can, plug them, and wait for another intrusion to get more clues.”
Thanks to the work of @jeffchannell I didn’t have to look far for a starting point: the sh404sef SEO component had some vulnerabilities that go way, way back (Jeff tracked it to 1.0.20, but I saw it in a 1.0.11 install.)
This was my first Joomla component update for this client, so I took the opportunity to document the process for anyone new to Joomla work (or for myself, when I google “how to update a Joomla component” in 3 months…)
Get the site local
Do not update the site live and see what happens. It’s going to be a mess. Download the entire site and database dump, and set up a local website as a sandbox testing area. Then put it in source control so you can revert easily while you try out your changes.
You’re going to want to pay attention to the PHP version in your sandbox. If the Joomla version you’re using is before 1.5.15, PHP 5.3 won’t work, so you may need to install a different version on your development box, ideally the same as in production. Yes, the next thing we’ll be doing is a core Joomla upgrade, but I want to spend a few more days getting to know how the site works before tackling that.
You’re also going to have to make some changes to your configuration.php file. In theory you could change your host file to trick your computer into thinking that the production URL lives there, but you’ll want to be able to compare the test site and the live site, so to do that on the same computer you’ll have to at the very least update the $live_site variable to your local site URL. For component updates you won’t be uploading the configuration, so this isn’t a big deal, and frankly, uploading the whole site from your test area isn’t wise either, in my opinion – read on…
Create and document a procedure
Try the update in your sandbox, writing down each and every step. This is so you can replicate the process in production. That’s right, you don’t want to update the site locally and just upload the whole thing, you want to do the process twice. Why? Maybe it’s a debatable thing, but your update might change something in the database you hadn’t thought of, or the component might update something remotely, or some kind of side-effect might show up that you can’t explain other than “it works on my dev box…” Also, if you document the process you’ll be able to adapt and reuse it on other sites, which will save a ton of time, and someone else can do the deploy if you write it up properly.
Test test test
Having a local site means you can compare everything between dev and prod, and having the site in source control means you can revert as many times as you need (remember to store your database dump in source control too so you can revert that at will) to repeat a step in the process.
Prior to deployment, it’s a good idea to setup a virgin version of the sandbox again from your original downloads and try the process one last time – it’s amazing how many “oh, just patch that on the fly” events happen during an upgrade, and if you missed one it’ll break everything. When you’re doing this deploy, work directly from the plan you wrote out, and pay close attention or you’ll find yourself skipping ahead. You’re testing the component but you’re also testing your plan. Even if you never use it again, this is a very important process that not enough developers adhere to – it’s brought joy to so many operations people I’ve worked with over the years, and that’s for a reason.
Finally, run the procedure on your live system after backing up the whole site and the database. Be sure to put the site in maintenance mode during the update so you can be sure that there’s no client impact (other than the site being offline) and that the database doesn’t get confused midway through the install from user activity around the component you’re replacing. This is also key in the event you need to back out (replacing the site with your backup,) so no data is lost.
Lather, rinse, repeat
That’s how I do my upgrades for Joomla and just about everything else. The sandbox setup is reusable, but you’ll want to re-download the full site and database every time you plan work to account for anything that might have changed on the site via public or other admin users. It might seem like overkill, but in my honest opinion it’s a sign of a mature development cycle and the cost to do this is minimal compared to the cost of fixing problems on a live site after they happen.
Do you want this kind of care and attention for your website? Hire me!