PHP security under scrutiny

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.