Original URL: https://www.theregister.com/2006/12/21/php_security_scrutinised/
PHP security under scrutiny
PHP = pretty hard to protect?
Posted in Channel, 21st December 2006 11:22 GMT
A week after a prominent bug finder and developer left the PHP Group, data from the National Vulnerability Database has underscored the need for better security in PHP-based web applications.
A search of the database, maintained by the National Institute of Standards and Technology (NIST), found that web applications written in PHP likely account for 43 per cent of the security issues found so far in 2006, up from 29 per cent in 2005. While flaws in the language itself account for a very small percentage the total, the problems with PHP underscore the difficulty that developers - many of them amateurs - have in locking down applications written in the language, said Peter Mell, senior computer scientist for the NIST and the program manager for the National Vulnerability Database.
"In the dynamic programming language (and) scripting realm, we certainly have a problem," Mell said. "Any time a third or more of the vulnerabilities in a given year are attributed to a single language, you know you have a problem."
The concerns come as attackers and security researchers have increasingly focused on finding flaws in web applications. Earlier this year, one researcher highlighted the upward trend in web flaws in general, and PHP in particular, when data for the first nine months of 2006 showed that vulnerabilities in web applications had taken the top three spots in a list of most common flaws. The researcher, Steven Christey, found that about 45 per cent of the vulnerabilities found as of September were either cross-site scripting flaws, database injection bugs, or PHP file inclusion vulnerabilities.
At the heart of the debate is the popular language, PHP - an acronym that originally stood for Personal Home Page tools when it was a small project created by Rasmus Lerdorf in 1994. Two Israeli developers, Zeev Suraski and Andi Gutmans, rewrote the language parser in 1997 and changed the name to PHP: Hypertext Preprocessor, adopting the recursive naming convention historically used by some Unix programs. The language is now used by websites hosted on nearly 20 million domains and 1.3 million IP addresses, according to data collected by Internet monitoring service Netcraft for its October 2006 survey.
The popular dynamic web programming language came under scrutiny last week after a longtime developer, Stefan Esser, left the PHP Group's internal security team, criticising its members for not responding quickly to security issues. Members of the PHP Group fired back at Esser, stating his reasons for leaving were less about security and more about not working together with the team.
Esser quit the PHP security team on 9 December, after a rocky relationship with the group, but claimed that security issues constituted his main reason for leaving.
"The reasons for this are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile," Esser wrote in his blog. "The PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user, but the moment you criticise the security of PHP itself you become persona non grata."
Esser promised to publicly release more advisories on the security holes he finds in PHP and will not hold back, even if there is not a patch available for the problem, he said. Esser did not respond to requests for comment from SecurityFocus.
The PHP Group and Zend, the company founded by the two original Israeli developers that rewrote PHP in the mid-1990s, have disputed Esser's version of events.
"I do not believe the main reason for his disengagement has to do with the way we deal with security issues, but the way he interacted with other people on the team," said Zeev Suraski, co-chief technology officer for Zend. Suraski also stressed that the PHP Group has looked for ways of making web applications written in the language more secure, in spite of less security-savvy developers. The move away from making a set of global variables accessible by PHP scripts, for example, attempted to make the language more foolproof, he said. It also took more effort to develop than to create version 5.0 of the language, Suraski said.
"We have shown in the past that we are willing to change defaults and sometimes to remove features, just to make it more difficult for developers to make security mistakes," Suraski said.
Yet, mistakes are still being made and in record numbers.
A search of the National Vulnerability Database revealed that, as of 15 December, out of the 6,198 vulnerabilities recorded in 2006, as many as 2,690 - or 43 per cent - had the word "PHP" in the description. A random sampling of the flagged flaws showed that the search appeared to only reveal issues in PHP applications. A search of the database using "PHP" as a vendor flagged some 84 vulnerabilities for 2006 (including in optional components of the language, such as PEAR), while a search using "PHP" as the product returned 33 bug, ostensibly in the core functions.
The vast numbers of bugs attributed to PHP applications is not surprising given that many amateur developers create their websites using the language, said NIST's Mell.
"I think it is tough for the general public to write secure dynamic web applications," he said. "As much as possible scripting languages for Web sites should be dummy proof. In many incidences, I, a security professional, wondered how to code some bit securely. I wanted to, but how to do it was not immediately obvious."
Flaws in PHP applications have caused headaches for many webmasters. A year ago, the Lupper worm spread among vulnerable applications that used the PHP extensions for extensible markup language (XML), or RPC-XML. Other worms have utilised flaws in popular PHP bulletin board programs as well.
Continuing to educate PHP developers on the latest techniques to secure their applications is extremely important, said Chris Shiflett, a manager in the web application security practice at OmniTI and author of O'Reilly's Essential PHP Security.
"To say PHP has a security problem suggests that it's impossible to develop a secure PHP application, but to say PHP doesn't have a security problem suggests that everything is perfect - neither is true," Shiflett said. "Web application security is a rapidly evolving discipline, and it's difficult for the average developer to keep up with the pace."
Developers need to start thinking about security as soon as start designing their applications, he said. Moreover, the focus on securing code needs to continue throughout the life of the website, he added.
"Over time, web application security should start to mature just as other security disciplines have, but that only means the pace of evolution will slow down, not stop," Shiflett said. This article originally appeared in Security Focus.
Copyright © 2006, SecurityFocus