A quick snapshot in time reveals that Web applications written in PHP likely accounted for 43 percent of the security issues found in 2006, up from 29 percent in 2005 (Institute of Standards and Technology (NIST) National Vulnerability Database). By 2015 you would have expect that to have been addressed by the ever so vociferous community on the strengths and benefits of Open Source. The sad reality is largely NO it is worse than ever.
In Ferrara’s findings:
- 93.3 % of all PHP 5.6.x installs are insecure
- 63.4 % of PHP 5.5.x installs are insecure
- 89.6 % of PHP 5.4.x installs are insecure
- 66.1 % of PHP 5.3.x installs are insecure
- As for PHP 5.2, no versions of that branch are considered secure, just write it off
Ipso facto, any Datasource that sits behind applications running on PHP v5.2 or earlier are potentially a time bomb. If you have customer or financial data in such a state and connected to a public network you are strongly advised to DISCONNECT IMMEDIATELY. Or risk being named and shamed.
PHP is a popular general-purpose scripting language that runs through its own web application service delivering automated functionality and data connectivity as an abstracted layer on top of webservers and databases. Webservers and databases that in turn sit on top of an Operating System. All this stacking ‘on top’ hints at the challenges and problems that raises the risk of this type of technology disproportionately to the cost value its Open Licensing would elude to outside of a disciplined developer and systems administered environment. LAMP is the acronym for such an archetypal model of web service solution ‘stacks’.
A contributor to PHP’s woes is it’s often defacto choice for amateurs venturing into web publishing and distributed application creation. It is freely available as is its database sidekick MySQL deployed more often than not on top of an Apache webserver running on either a Windows Operating System or Linux distribution. The LINUX option represents a zero licensing cost starter platform which is proving a security nemesis.
PHP is not after all a true programing language per-say, it is a scripting / Mark-up language. PHP is a very simple to learn and implement language. Its ease of adoption comes from the fact that at its simplest point of entry it offloads much of the detailed and complex functions onto its application server engine that abstracts users from the need to learn a developer language and associated skills and disciplines that require code compiling etc. In reality it’s a simple sudo-english mark-up language at its core.
To avoid the misconception that PHP is just an amateur’s toolkit, it is far from that. PHP represents the underlying technology for hundreds of third party solutions both commercial and home grown. WordPress for example one of the most widely adopted Web Content Management and Blogging platforms is based on this technology. Since version 3 PHP has also had basic object-oriented programming functionality and improved in PHP 4 opening it up to greater potential by professional developers. PHP is currently at version 5.x and forecasting a next major release to version 7 this year which we can only hope will include upgrades to address current security weaknesses.
To be fair PHP itself is not 100% to blame. Just as a gun will not jump up and shoot someone, it requires a catalyst. In the case of a gun it would be a human with malintent. In terms of PHP it could be a sudo-developer, aka scripter / web publisher with aspirations, building an application and linking databases that are exposed to malware, or running an unpatched or out of date version of PHP out with any disciplined testing or security hardening practises. The malware exposure comes in because of the ease with which it is now possible to stitch together a web application means harnessing a ‘stack’ of technologies that each have their own strengths and weaknesses magnifies the weaknesses. The main weaknesses sit at the joins, where one technology connects to the other. It is the IT no-man’s land, where neither offloading tech stack nor receiving tech stack can own the whole process.
The brave new world of Cloud computing has spawned the mega horror prospect of this with publicly available Application Programing Interfaces (API’s) that allow applications to comprise of multiple 3rd party service and associated technology connections. Then there are mobile platforms that place these interfaces on devices that are often out with any corporate systems management. (Cloud Security Alliance’s (CSA) Top Threats to Cloud Computing report).
By way of illustration the open source SSL validation is completely broken in many security-critical applications and libraries, such as JSSE, OpenSSL, and GnuTLS used in varying degrees and versions of MySQL, PHP and versions of the Apache webserver and LINUX Operating System. Vulnerable software includes Amazon’s EC2 Java library and all cloud clients based on it; Amazon’s and PayPal’s merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware—including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android—and all applications employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack.
The root causes of these vulnerabilities are badly designed APIs and data-transport libraries (such as cURL) which present trained developers with a confusing array of settings and options, not to mention the mark-up amateur sudo-developers. (Martin Georgiev and others – The University of Texas at Austin).
The list is endless in terms of code/mark-up and application Server interface examples and encompasses not just PHP but its associated ‘stack’ of technologies. This highlights the second major challenge, the updating of such a patchwork quilt of technologies. For amateurs getting this ‘stack’ all working together represents the pinnacle of their capabilities, to then dip in and patch one or other component is sometimes a challenge too far. Not to mention when they do the risk of introducing instability and competency to effectively trouble shoot subsequent potential incompatibilities with other parts of the stack is often beyond their ken. In fact I have found many professional and commercial implementations of PHP and its family of associated technologies and dependencies in a shocking state of security readiness. In most case this comes down to a lack of old fashion documentation and knowledge transfer of the original build, so people fear to touch, defaulting to the old school ‘if it isn’t broke, don’t fix it’. I’m afraid that simply does not qualify as an excuse, but in today’s ITC world of advanced persistent threats constitutes negligence.
When it comes to web technology or ANY technology that you expose to a public or internally shared audience, do so knowing that:
- It is not 100% secure – ‘Cleanroom development’, a technique pioneered by Harlan Mills was able to achieve rates as low as 3 defects per 1,000 lines of code. Clean room development is expensive and largely the reserve of NASA and military, commercial error rates at best are more like 20-50 errors per 1,000 (“Code Complete” by Steve McConnell). Now sit down first and then extrapolate your amateur developer’s error rate.
- Your risk of compromise escalates to ‘Very Probable’ IF you do not keep everything patched up to date – Since the three day terror attack that started in France over 19,000 French websites have been compromised. ‘19,000 French websites hit by DDoS, defaced in wake of terror attack’.
- Your Businesses very existence may rely on the ability to exercise continuity of service that will rely on the ability to re-build and deploy systems without access to the original developers, engineers or designers – Documentation and a Business continuity and disaster recovery planning.
Security is not an option it’s mandatory, and in a world of rapid technology evolution use of anything but the qualified IT professionals to do a job represents a serious business risk. In that I do not mean any old hack who embellishes their title with an arbitrary ‘Professional’, ‘Architect’ or ‘Engineer’ suffix/prefix. These terms traditionally represented badges of confidence and credibility for traditional business decision makers but have regrettably been undermined by the unqualified, un-professional and those who are neither members of the Institute of Architects nor Institute of Engineers. For more on the professionalism in our IT world see my earlier post ‘Professionalism in IT – Evolution or revolution?’
If you’re still not convinced head over and get a copy of Essential PHP Security – 30 exploits in a quick read. ‘Bang, Bang the mighty fall…..’ (from song Bang, Bang by B.A. Robertson).
Further reading:
- Usage statistics and market share of PHP version 5 for websites – http://w3techs.com/technologies/details/pl-php/5/all
- PHP Install Statistics – http://blog.ircmaxell.com/2014/12/php-install-statistics.html
- Diseconomies of Scale and Lines of Code – http://blog.codinghorror.com/diseconomies-of-scale-and-lines-of-code/
Nigel Gibbons ~ Welcomes you 
Posted on January 12, 2015
0