A cautionary tale of unfolding doom and despair

We have laid out the background to PHP in the previous articles leaving you with a minor cliff-hanger.  So, what’s happening with PHP and why are we so concerned about it?  Why the tsunami analogy running through the articles?

Where does all this lead?

The web’s reliance on earlier versions of PHP is a real threat, and it’s a multi-faceted one. 

We’ll lay out the potential risks and how they can be approached and dealt with – and they can be dealt with. 

In part one we mentioned WordPress, Magento and OpenCart amongst others.  This is not small beer; according to some statistical research WordPress alone is responsible for up to 60% of the world’s CMS (Content Management Systems) – sixty percent!  All of those systems, all that web content, is dependent upon PHP.  WooCommerce and Magento are the most prevalent eCommerce systems in use in 2018 (although it is a fairly fragmented market) but again both are reliant upon PHP.

At this point you could well be forgiven for thinking that we are hitting a small nail with an extremely large hammer, but as was mentioned in Part 2, PHP 5.5 and 5.6 (PHP 5.x) stopped receiving support of any kind in December last year and these are still the most widely deployed version of PHP underpinning the web.

Despite the demonstrable benefits of Version 7.xx of PHP in terms of support and performance – PHP aims to fully support all stable releases for 3 years – uptake has been relatively slow.

Should conversion from version 5 to version 7 continue to drag there is a very real prospect that increasing numbers of websites will be resting upon a “shaky pillar”, or in other words an unsupported programming language with no prospect of patches should further vulnerabilities emerge.  Any weaknesses still within 5.xx will remain and can be exploited.

In short, critical sectors of the internet will be exposed to security threats.  Those threats will be both existential in terms of direct attacks against websites, taking them off-line or seriously compromising their operation.

Exposure! How?

Under the General Data Protection Regulation (GDPR), a company has the ultimate responsibility to ensure the safety and integrity of its data.  The Information Commissioner’s Office (ICO) made allowances for the distributed nature of the modern world by offering guidance on ensuring that your third-party vendors adhere to the provisions of the regulation, but that does not absolve you of your responsibilities.  It is highly likely that continuing to run a website or a business that uses personal or sensitive personal data on an ageing and unsupported platform would not be viewed kindly in the event of a data breach.  It would, we strongly suspect, constitute a breach of your data protection obligations, with the potential for investigation and sanctions that would bring.

The problem for many companies is that they simply do not have direct control over the exact constitution of their web platform – that is the purview of various other actors, from their web developer right through to the hosting company. 

While it could be construed that they have a responsibility to bring and keep their platform up to date, patched and secure, are you sure this is the case and do you have certainty that this is being done? 

During your GDPR preparations did you review all the contracts and terms of business with third party vendors to ensure that they were obliged to comply with GDPR?  Did that include examining exactly how they were maintaining your web platform?

Perhaps the worst possible outcome of this situation is not only the reputational damage, re-direction of resources to deal with, loss of business due to attacks but the subsequent need to notify the ICO only to discover that they ultimately find you responsible for the failure, and levy fines accordingly. 

It doesn’t take too much imagination to see the likely result of such a disaster.

What can you do?

This is not an impossible situation but addressing it will require investment. 

In-house expertise costs money, there is no getting away from that, as does paying for reliable advice.  This price however is likely to be insignificant compared to the potential damage caused by doing nothing.

Take control of your web presence and ask your web partner. This is exactly what we have been engaging with our own clients on for the past 2 years.

If your web partner doesn’t know the answer to these questions then are they really the best partner for you.

Likewise as well ask them if you’re on a shared server account, the chances are you’re probably on an account that has many other sites that are unmanaged and not under the control of your own web developer? In these cases those servers will likely only run on either PHP 5.xx or 7.xx but not both.

Paying £80-150+vat per annum for your website, then this will likely only include hosting (and if you’re lucky managed backups on the same server, we only backup to a 3rd party location which costs more but provides more peace of mind). Given this it is very likely there is no allocation of budget for ongoing maintenance work. Importantly have you asked if this is the case?

NOTE: Another 2 means of sweating the server asset we come across is that the business email is hosted on the same server as the website (for more info see out cautionary tale about Squirrel Mail) AND that the same server is used to send out form based mail, ask your developer if they use Local Host rather than Mandrill or SendGrid (which both cost an additional fee)?

You could physically reclaim your web presence by setting up your own web server– thus giving you complete control over what runs on the server. But even then you’d need to have a systems admin to manage this on your behalf, as well as someone to manage the website platform. This daunting and is not without expense, but it is not the only way to retain control. As Platinum partners we have a relationship with UKFast that you can piggy back if this is of interest to you?

So clarify with your current provider exactly what they are doing for you.  Get right into the nitty-gritty of the LAMP (Linux, Apache, MySQL & PHP) stack if applicable (and it probably will be).  Insist, contractually, that they keep your website right up to date and that they are not relying on unsupported versions of PHP. You need to know that this will likely come with a cost though.

Find out if you are running on a multiple account type shared server.  This is very common, but it has a number of risks, find out more from our article on "How Much Do You Trust Your Neighbour".

Are you comfortable with the notion that another company’s failures are compromising your security, possibly your livelihood?

It’ll be alright, this is just another internet panic.

No, it isn’t.  We wrote in Part 2 about the effects of the WannaCry attack.  It was possible because of a flaw in a Windows sub-system.  The attack paralysed the NHS here in the UK because as an organisation they hadn’t applied the patch to fix the problem which Microsoft had issued weeks previously.  Had they done so they would have avoided the cost of recovering from the attack – a cost now estimated to be £92 million.

No – the originators of the attack shouldn’t have created it, it shouldn’t have been distributed and thanks to the advice to Microsoft from the National Security Agency (NSA) in the US, it should never have had the effect that it did.  Knowledge, warnings and patches flowed right down the chain until the last link – the user.  An institutionalised failure to properly protect themselves led to disastrous problems and costs.  We’re not saying that the users were responsible for the mess, they weren’t, but it was a failure at the end of the chain that allowed the propagation of a problem that should literally have been nipped in the bud.

So it is with PHP.  Version 7.xx has been out for some time now, it is stable and offers considerable benefits to anyone who’s website relies on it.  But failures down the chain – at the web platform level – mean that as the sun sets forever on the older Version 5 there are still far too many websites (in particular open source platforms) dependent upon nothing going wrong.

Crossed fingers is a very poor business strategy.

We can help

Inspire have been watching these developments with real concern.  We have taken all steps to ensure that our clients are protected against possible problems, but it is apparent that wide swathes of the web are going to be left vulnerable after 17th December this year.  If you would rather not be in their company, contact us to discuss what you can do and how we can assist you to face the future with confidence.

Sources

Code in WP

Cloudways

https://www.inspire.scot/blog/2018/02/05/how-well-do-you-trust-your-neighbour281

Cautionary tale about Squirrel Mai

ICO

IT Pro

Hayden James