The Ticking PHP Time Bomb

In just a few months time, PHP 5.6 and PHP 7.0 will no longer be receiving security patches. PHP 7.1 will have another 12 months to go, with PHP 7.2 another 12 months after.

PHP 5.6 was lucky to get a reprieve - it was due to expire a long time ago, but got an extra year of updates, continuing to receive security patches up to now, but come the end of the year PHP 5.6 will be considered EOL. Even the more recent PHP 7.0 also becoming EOL at the same time, and security patches will no longer be made available.

It's obvious to see why PHP 5.6 was lucky, the stats show that there could be up to 70% of PHP websites still running on PHP 5.6 or lower. This means potentially in the future if a hacker found a major hole in that version of PHP, this would potentially leave a lot of websites that would be generating a major headache for their owners and the script kiddies would have a field day.

What does this mean ?

For your website, if you are actively developing and maintaining your website, then the chances are your PHP website will still be able to run on a modern PHP 7.1 or 7.2 setup without any issues. PHP 7.2 may throw more issues into the mix with deprecated functionality and stronger requirements for better code, but your developers are probably running PHP 7.2 somewhere along the line, or have the ability to show issues for PHP 7.2 from their build environments.

However, I know there are still sites out there that run on PHP 5.6 (and earlier!) that should really be moved on, either updated for PHP 7.2 or if the code is unmaintainable due to years of abuse by developers, simply rebuilt in a modern framework. These sites probably include old libraries that haven't had the joy of an update or have long since been abandoned. The libraries probably have bugs and security holes in themselves, never mind the hosting platform or the website code itself. In some cases library code can be updated easily, others not.

The older websites probably have horrible looking admin interfaces making work flow slow and cumbersome, or if you took a peek in the error log, you would see a log file full of warnings and notice errors, each time these happen, they slow the website down. A bad developer will simply "hide" these away with error_reporting. With an attitude of "if I can't see them there's no bugs to fix" - what is the rest of the code going to be like?

A log file full of noise makes it harder to find the real bugs in the website and it also makes it harder to spot hacking attempts.

These old websites probably have a frontend that doesn't validate, maybe it isn't responsive so over 50% of the average website traffic can't view the website correctly on mobile phones, or it looks like the 90's called and want to bring Mosaic back for browsing or maybe Netscape with the blink tag.

XSS and CSRF are good friends of the website visiting it regularly, along with their best mate SQL injection. These issues would have a great time having a party on the server, followed by the finale when the fat lady sings, SPAM, because the developer used the PHP mail function and a bit of script copied from a website page written ten years ago. At this stage your web server and domain is blacklisted never to send mail again.

How annoying would that be if your customers couldn't get their order emails, imagine the number of support calls and the time cost to deal with them?

Why upgrade?

Allowing your website to run on a platform that no longer receives updates may open up your site to getting hacked, the last thing you want to find is a hacked site with all your data exposed, or someone inserting content into your page, mining crypto-currency, hidden adult material links, malware, etc...

The best hacks are the ones you may never know about, the data is syphoned off from your database, and because your hosting setup doesn't notify you of odd behaviour, you will never know of the hack.

It is important that you know the server infrastructure and website is secure.

I read recently that hackers will sit on data for sometimes years waiting for the right opportunity to come along to bring together the data, with high profile hacks such as the recent equifax one, or the yahoo hack, or <insert high street shop> hack (in fact as I write this, yet another high street shop in the UK superdrug has been hacked), you bring that data together and suddenly you have the right data for some serious financial gain. Phishing becomes so much easier if you know a lot of information on a potential target.

Your website data might not seem a lot to you - although it should be! Any data you hold should follow the 3 core principles of the security triage, confidentiality, integrity, and availability - CIA. The great GDPR rush earlier this year, shows that companies are lacking in some of the basic principles with regards to data, holding far more than they need to be (why do I still need to give a fax number on some sites!), and definitely not managing it correctly. Worst still if you thought the GDPR thing was a one time checklist, you should note that consent needs to be managed, you should only hold consent for as long as your business requires. You should re-consent when your requirements change, and you should consider refreshing consent periodically.

When your data is combined with other websites data, the data suddenly becomes a lot more valuable to the hacker. Combined with password reuse, things can get bad pretty quickly for unsuspecting victims, especially if they crack the passwords from your data!

If you have a popular website, the bad press involved with a hack could potentially damage your business credibility and reputation, leading to loss of income, or worse.

From experience the sites that don't get the updates and aren't actively managed, tend to be the ones with the least security, and the most likely to be hacked by even the basic of script kiddie tools. The passwords might be hashed, but it's md5, and the only knowledge of salt is what gets used at the table or when cooking.

These sites are the ones once built, then abandoned by the developer who is never to be seen again. The owner of the website is probably unaware of the ticking time bombs waiting to go off. The website is shiny and new when launched several years ago, but it's not patched, it's not upgraded and rapidly becomes obsolete.

Or how about the web agency, they have relied on an in-house platform to build a website for clients, with the possibly hundreds of sites running off it, but it's not a central platform and upgrading the sites won't happen without significant cost. Or they've deployed an off the shelf CMS but didn't include a support contract to keep them updated with security patches.

What about the WordPress site that's built by the developer, but the owner is never taught how to update so they are left with an unpatched WordPress setup. Due to the popularity of WordPress, it's always under scrutiny by nefarious beings and whilst things has got a lot better in terms of security, older WordPress installations still have issues, the plugins have more issues, and it's probably luck more than anything that the WordPress site hasn't been hacked yet, or as I mentioned earlier you don't know you've been hacked and the worst has already happened...

The case for speed

Upgrading to PHP 7.x has some major advantages too, speed and memory use was massively improved with the PHP 7 release, and continues to get better with each point release. I've seen stats showing up to 150% speed increases if not more, this makes a huge difference in speed perceived by the end user, and would help with SEO ranking if your site responds faster. A fast site leads to a happy user, how many times have you abandoned a purchase because the website was running slow?

So what do I do next ?

If you have a good developer, talk to them, get them to upgrade your website, libraries, and server platform as required. Get them also to explain the issues with upgrading which they should be fully aware of.

If you don't have a good developer, I could help advise on what could be done to improve the situation, from patching the server, patching the website, upgrading the site and libraries, to rebuilding the site if needed. I would audit the code and site, run tests for existing issues, build unit/functional/acceptance tests for the existing site as required, and then go about updating the code and libraries to bring it into a modern age, maybe give the website a bit of polish to scrub away that old functionality and bring in smoother work flows that just work. I would then re-run the tests to ensure functionality hasn't been lost with the refactoring of the code.

You could do nothing, in which case, good luck, if your hosting provider upgrades php you might be lucky, your code might still run, or you may find that code that was working stops working due to PHP function deprecation (hello mysql_* functions, I'm looking at you!), or the site starts filling up with errors with Countable messages, or any number of deprecated functionality messages. You might still be left with out of date libraries, a CMS that has you banging your head against a wall, or a website that doesn't work responsively on mobiles or tablets, which in the long run will cost you as traffic starts to dwindle towards nothing.

Remember

Having a website built isn't a one time thing, you can't just build the website and expect it to continue functioning forever. A good developer will always talk about on going support, either updating the website with new functionality, or keeping it patched. The hosting platform needs to be kept as secure as the risk appetite allows, active management and patching needs to be happening on the server, you can't just spin up an AWS EC2 instance and leave it, you need to patch it, you need to secure it, firewalls, IDS/IPS, monitoring all needs to happen, and is an ongoing process.

You also need to be updating the content on the website, a stale site will rapidly lose ranking on google and nobody will then visit your website as you end up several pages into the results.

Yes it does cost time and money, but what's worse, a small monthly support fee, or a headline "Site hacked, thousands of user details stolen" followed by a fine for up to 20 million euros or 4% of your turnover under GDPR... I know what I'd rather pay.