AOH :: ISNQ3465.HTM

PHP apps: security's low-hanging fruit




PHP apps: security's low-hanging fruit
PHP apps: security's low-hanging fruit



http://www.theregister.co.uk/2007/01/11/php_apps_security/ 

By Kelly Martin
SecurityFocus
11th January 2007

PHP has become the most popular application language on the web, but 
common security mistakes by developers are giving PHP a bad name. Here's 
how PHP coding errors have become the new low-hanging fruit for 
attackers, contributing to the phishing problems on the web.

PHP became one of my favorite languages because of how quickly one can 
write a highly functional, standards-based web application with a 
database back-end. Unfortunately, attackers are taking these 
applications down even faster than they appear.

I'm sure I'll receive my share of flames under this column - but this is 
unfortunate, as I would hate to see such a nice language start to 
languish - however, for many folks there's no easier way to compromise a 
web server than to find a vulnerable application written in PHP.


The great rise of PHP

Let me start by saying that I'm a big fan of PHP and have written a 
number of web applications with it over the years. It's a great language 
that is now object-oriented, powerful and easy to learn, has a simple 
syntax, integrated SQL connectors, and high performance. It's simple to 
compile, very cross-platform, and has become arguably the dominant 
language on the web - thousands of commercial and open-source 
applications are available and in use.

The developers of PHP are doing many things right, from offering 
excellent support, protecting intellectual property in commercial 
applications, maintaining both the current release (5.x) and one prior, 
extending the object oriented approach, working with the community, and 
all sorts of other things. But not everything is rosy in the PHP world.

The problem is, PHP applications accounted for about 43 per cent of the 
security issues in 2006, according to the National Institute of 
Standards and Technology (NIST). Diving deeper into this number, there's 
the issue of determining who's most responsible for the problem. Do we 
blame PHP itself for being an insecure language, or do we blame the many 
inexperienced programers who have created vulnerable PHP applications 
and released them to the world?

The fact is, the vast majority of vulnerabilities found in PHP 
applications are due to poor programming practices, and are one step 
away from the language itself. Poor programming is a security problem in 
any language, but with PHP in particular the coding errors often lead to 
common web security problems such as Cross-Site Scripting (XSS), include 
file injection vulnerabilities, and database injection or manipulation 
issues.

What strikes me is how the really basic mistakes pop up again and again.

A quick tour through the SecurityFocus vulnerability database and 
Bugtraq and a website like milw0rm reveals many PHP applications ripe 
for exploitation. Many require only very simple file inclusion exploits. 
And that's exactly why some people are exploiting them. It's the 
low-hanging fruit.

It only takes a few minutes to understand a typical web application's 
coding errors and then search for vulnerable installations using Google. 
In just a few minutes, an average attacker with little talent and even 
less time can compromise a typical server.

While PHP application developers are by far the most responsible, there 
have also been numerous vulnerabilities in the PHP language itself. 
These are often harder to exploit, but when found they can affect the 
entire base of installed PHP applications on the web. So there's really 
two main issues at work here.

The recent departure of Stephan Esser from the internal PHP security 
team should also raise some eyebrows, especially after reading the 
explanation he gave on his blog about leaving the very group he founded. 
Even as a user of PHP myself and having a passion for security, I wasn't 
aware of some of the ongoing internal issues. Esser's Suhosin hardening 
project looks like one that more people should check out.

I'm focusing on the user issues in this article, but the PHP Group can 
still take some of the blame. They are the ones who design and grow the 
language, and they've chosen to take a certain route - giving 
application programmers more than enough rope to hang themselves, in 
terms of security - just as any language does. Many developers, 
including some very experienced ones, have indeed hung themselves due to 
easily made mistakes that lead to poor security.

Anyone who's experienced a server compromise due to a PHP app they 
didn't write and didn't audit has probably done some soul-searching and 
become much more wary of all the free PHP apps. I really enjoy using 
PHP, but I'm quite cautious of most applications unless it's one that is 
a large and successful project with a real focus on security, a 
dedicated security mailing list for announcements, and so on.

There are many infrastructure tools needed to secure a typical PHP web 
server from an unknown developer's mistakes. While this is beyond the 
scope of the article, I'll just list some of them here: web server 
hardening, CHROOT/JAIL, PHP as a separate user, an IDS with daily 
updates, a web application firewall, and a file integrity monitor to 
help detect the inevitable server compromise.


The Windows defense?

PHP shouldn't be blamed for its popularity, so I don't want readers to 
get the wrong idea. Many lower level languages like C/C++ are even more 
popular and give developers far more rope to hang themselves than PHP. 
Therefore, there are other issues at play.

Applications written in every language can, will, and have had a myriad 
of security vulnerabilities over the years. It doesn't matter if it's 
C++, Perl, ASP, Visual Basic, Python, or Ruby and Ruby on Rails. Every 
language or rapid development framework has its strengths and 
weaknesses. Personally, I've tended to avoid frameworks like Ruby on 
Rails, for example, because it felt like I was drilling my own teeth 
sometimes it's a little scary not knowing exactly what's going on 
inside, just in case something goes wrong.

PHP has had the greatest appeal among new web programmers eager to build 
database applications and support XML and Ajax. The language has 
welcomed thousands of new programmers to the joy of programming. The PHP 
Group should be proud of that. But it comes with a dark side.

I have no doubt that some PHP Group developers shake their head at the 
very basic security mistakes that many new programmers make. The 
problems are all over the web. They're user issues, so they probably 
don't concern themselves with them. But they should.

The same mistakes are being made over and over again, and people aren't 
learning. This is an opportunity for the PHP Group to provide something 
new. How about a new SAFE_MODE that actually makes things safer in the 
language, and doesn't try to do what can already be done with 
infrastructure?

I'd like to see new defaults that limit include() and require() to only 
allow local files, thereby avoiding remote file injection. It would be 
nice to have a global way for a script to ignore all variables in the 
URL, avoiding unexpected variable manipulation and XSS forgeries. Maybe 
there's even a way to force users to filter input and escape output 
every time, helping to avoid SQL injection and all sorts of other common 
problems. That last one would go a long way.

It's an awful lot easier to compromise a typical LAMP server 
(Linux/Apache/MySQL/PHP) than it is to exploit a full-patched modern 
Windows desktop. It's not the OS, it's the application. Part of it is 
the popularity of PHP itself that has put so many insecure applications 
on the web, and part of it is how easy it is to make security mistakes 
when coding PHP. Without a defense-in-depth infrastructure, which is 
often lacking on a typical LAMP server, a PHP programming flaw often 
results in a full web server compromise.

The short of it all is, PHP apps can be made secure, but far too many 
are not.


The bigger picture

Why should the PHP Group care more about the mistakes of inexperienced 
programmers? That's an easy one. Many websites being exploited today are 
turned into phishing sites designed to steal money and identities from 
people who don't even know what PHP is, and in many cases barely know 
how to operate their own computer. In other words, the applications are 
abused by the criminal element. PHP doesn't need to stand for Perfect 
Haven for Phishing.

There are all sorts of automated scripts out there that search for 
vulnerable PHP applications, exploit them when found, and then 
automatically download a set of phishing HTML files and images that make 
John's Awesome Blog suddenly look like the Bank of America's login page. 
This also happens with ASP and Perl applications too, as well as those 
written in other languages, but today PHP is far more popular a target. 
That website owner, John, might be held responsible too if there weren't 
dozens of these incidents each day.

I'm not saying the PHP Group is responsible, but they could help. As 
architects of the language they should consider ways of hardening the 
language and its defaults against some of the real basic mistakes so 
many people are making.

I'm also not saying they should make PHP idiot-proof think of all the 
wasted cycles and extra code trying to anticipate a thousand common 
mistakes! But there's an opportunity to continue to grow PHP without 
being at the expense of the security of the Internet as a whole.

If the PHP Group decides to take a leadership role in this, by adding 
new features or functionality that help new programmers make fewer 
common security mistakes, we'll all be better off.

This article originally appeared in Security Focus.

Copyright 2007, SecurityFocus


_____________________________
Subscribe to InfoSec News
http://www.infosecnews.org/mailman/listinfo/isn 
 

Site design & layout copyright © 1986-2014 CodeGods