Common PHP Security Mistakes and What You Can Do About Them

 
 
By Brian Prince  |  Posted 2009-08-10 Print this article Print
 
 
 
 
 
 
 

Researchers at Fortify Software have compiled a list of the most common vulnerabilities found in PHP code. Here is what they found, and some advice on what developers can do about it.

Earlier this year, the SANS Institute teamed with a number of different vendors and organizations to list the 25 most dangerous programming errors. This time, it's Fortify Software's turn. 

But rather than focus on programming errors generally, the company examined several popular PHP projects - such as TikiWiki and phpMyAdmin - and compiled a list of the 10 most common vulnerabilities found in PHP code. Many of them will sound familiar to developers, such as path and header manipulation issues.

"Many of the vulnerabilities, such as cross-site scripting, can indeed occur in Web applications written in almost any programming language," Jacob West, director of security research at Fortify, told eWEEK. "However, some of the historical decisions made in the design of the PHP language over the years have made certain flavors [of] vulnerabilities easier to fall into and, we believe, more prevalent in software written in a PHP as a result.

"For example, PHP didn't include a parameterized SQL interface for many years, which makes SQL injection a more common vulnerability," he added. "On the input side, PHP's 'register globals' feature made all types of input validation vulnerabilities more prevalent." 

Two examples mentioned in the report are PHP's addslashes() and magic quotes features, which are intended to prevent SQL injection. These features, however, don't prevent all types of SQL injection, the researchers contend. Take this vulnerable code for instance: 

$id = addslashes($_ GET["id"]); 

mysql_query( "SELECT data FROM user_table WHERE id = $id"); 

"addslashes()will not prevent SQL injection since an attacker does not need to inject quotes to exploit the vulnerability - an attack as simple as 1 or 1=1 will suffice," the authors wrote. "In addition to providing weak defense against SQL injection, magic quotes can cause confusion when passing escaped data around. Typically, developers do not want to work with escaped data, so data must be un-escaped and re-escaped when necessary. This repeated escaping and un-escaping of data is inefficient and can lead to maintenance nightmares."

The report also takes the mysql_escape_string() function to task. Introduced in PHP 4.0.3 as a means to prevent SQL injection by escaping special characters, this function does not properly handle all characters sets and has been shelved in favor of mysql_real_escape_string().  However, mysql_escape_string() is still found in many code bases, the researchers contend. 

Other issues include poor validation against cross-site scripting, applications being too trusting of data from the database, and developers configuring applications to display as much information as possible. The remaining issues are dangerous file inclusion, code injection tied to dynamic code evaluation and variable overwrite vulnerabilities. 

"The specific threats vary from one type of code to another, but the root cause of many vulnerabilities is the ability for an attacker to introduce unexpected meta-characters into data involved in a sensitive operation," the authors wrote. "The best way to prevent meta-character vulnerabilities is with a level of indirection: create a list of legitimate data values that a user is allowed to specify, and only allow the user to select from that list. With this approach the input provided by the user is never used directly to specify the resource name." 

This may not be expedient if the set of legitimate values is too large or too hard to keep track of. While some resort to blacklisting as an answer, sticking to a list of characters that are allowed to appear in the resource name and accepting input composed only of those characters is a smarter approach, the researchers wrote. 

"The key is for the security community to continue to get more and more involved in getting security decisions right in the places they matter the most: language design, framework implementation and secure coding guidelines that developers can standardize on," said West. Editor's Note: This story was updated to add information about the Fortify report.

 


 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel