PHP poses threat to website integrity

"Patching no longer offers complete protection" says Professor John Walker, Nottingham Trent University

PHP poses threat to website integrity
PHP poses threat to website integrity

A new report claims that, with 82 per cent of websites using the PHP server-side scripting language today - and hackers targeting the code - the web hosting industry and its users have a serious structural security problem on their hands.

Originally developed back in 1995, PHP originally stood for Personal Home Page, but the acronym now stands for PHP Hypertext Preprocessor, a type of code that is interpreted by a web server - and which then generates a web page on the fly.

Because PHP commands can be embedded directly into an HTML source document, they do not need to call an external file. It is this degree of self-containment that has driven PHP's success, and the reason why hackers have targeted the code architecture.

SCMagazineUK.com caught up with Barry Shteiman, director of security strategy with Imperva – the company behind the PHP report - and asked him what corporates can do defend against the structural security issues that his report identifies.

There are three solutions, he says. The first involves constantly patching a platform and keeping it up to date, which is expensive and time-consuming. The second involves patching around the CVE advisories from NIST, and the third is to install a Web Application Firewall (WAF).

Professor John Walker, a Visiting Professor with the Nottingham Trent University's School of Science and Technology, said that all of these security strategies are made vastly more complex owing to the fact that most organisations typically have a range of PHP-enabled platforms in active use – many of which are in different versions. 

"I've seen corporates using everything under the sun in this regard, so patching ceases to offer complete protection. This is all part of the bigger picture of companies failing to have a defined software and versioning strategy," he said, adding that this lack of standardisation is the real cause of problems in most PHP implementations. 

The solution, says Walker - who is also director of CSIRT & Cyber Forensics at Integral Xssurance - lies in ensuring that the company has a well-defined software and versioning strategy - and sticking to that plan. 

"Basically this approach goes beyond the PHP security vulnerability issue and involves tackling the bigger security picture," he said, adding that taking a wider strategy allows businesses to defend their IT systems without the expense of specific remedies. 

Walker's observations were echoed by Jim Taylor, head of penetration testing services with ethical pen testing security consultancy Pentura, who said that vulnerabilities in PHP and Apache - where vendors have released relevant fixes - are still found to be vulnerable on a daily basis. 

“Exploitable vulnerabilities are not just restricted to the command injection vulnerability previously discussed and it is quite regularly observed that a great deal of public facing Web servers are poorly patched,” he explained. 

Against this backdrop, Taylor went on to say that it is key that system owners patch and update systems in a timely manner following a stringent corporate testing and patching policy that enables them to secure their systems and reduce the attack surface open to attackers. 

“ In addition, developers should be encouraged to update old code and stop releasing applications with known vulnerabilities. A security-in-depth approach should always be followed," he said. 

Back at Imperva, Shteiman likened the PHP issue to where the IT industry was with Windows XP security issues ten years ago, and where Java sits in the security space today. 

"Hackers realise that PHP is popular - which is why they target the code. There's also a huge gap between the time of vulnerabilities being revealed and patches being developed - in some cases, up to two years can elapse," he said. 

"Most hackers also realise that many users do not patch their systems, so they don't need to develop a constant stream of exploits for PHP - they can simply re-use some of the older PHP exploits," he added.