Feeds

PHP apps: security's low-hanging fruit

Why PHP apps accounted for 43% of security issues in 2006

Intelligent flash storage arrays

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

Top 5 reasons to deploy VMware with Tegile

Whitepapers

Choosing cloud Backup services
Demystify how you can address your data protection needs in your small- to medium-sized business and select the best online backup service to meet your needs.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.