PHP Insecurity: Failure of Leadership

About a week or so ago, I wrote to webappsec in response to Yasuo Ohgaki (æ›¸ã‹ãªã„æ—¥è¨˜) post about some issues with PHP’s security model.

For some time, I’ve been worried about the direction of PHP. As many of you know, I helped write XMB Forum and now help write UltimaBB. XMB in particular is an old code base, and UltimaBB, a descendant from XMB. I’ve done a lot to protect that code base from attack, and luckily, we’ve been missed despite some doozy and silly security issues. After writing PHP forum software for three years now, I’ve come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort.

PHP needs a proper security architecture, and support for newbie programmers. PHP’s raison d’etre is that it is simple to pick up and make it do something useful. There needs to be a major push by the PHP Development team to take this advantage, and make it safe for the likely level of programmers – newbies. Newbies have zero chance of writing secure software unless their language is safe.

Think about Logo for a minute. Logo can do some interesting things, but it is not a commercially useful language because it cannot do much. But it is an excellent teaching language. PHP is like Logo – it’s a simple and easy way to get into serious web development. It is possible to write large applications in PHP, so it is useful at that level. But it is inherently unsafe as it can do far, far more than Logo.

There are so many ways to break PHP that it is impossible for even experienced security professionals like me to code in it securely all the time. There are nearly 4000 function calls, and many of them have unintended consequences or have been inappropriately extended by something else.

At every turn, the PHP Development Team have made truly terrible “security” choices:

register_globals
magic_quotes_gpc (and friends)
PHP wrappers (see below)
safe mode
output, XML, LDAP, and SQL interfaces that intermingle data and query elements, which by their very nature are impossible to protect against injection attacks

All of these are broken. They are disjunct and have no security model. Some of the features, like PHP wrappers, are not well documented, and are a clear and present danger to PHP scripts and worse, they do not obey the weak “safe” mode restrictions. I bet few PHP coders are aware of them, let alone their security impacts.

http://php.net/manual/en/wrappers.php

PHP coders cannot rely upon their script running in a Unix or Windows environment, so they must code to the least common denominator. Hosters rarely upgrade to the latest PHP, even though it is safer. Even though programs could be ported to safer interfaces like PDO or the OO mysqli parameterized queries, programs cannot support this mode as it’s too rare. Even PEAR modules are hard or impossible to import in a shared environment, so favorites like PECL or ADODB which might help are not available, so programs ship with outdated and vulnerable libraries.

So why this whinge?

PHP must now mature and take on a proper security architecture, an over arching security model which prevents or limits attack surface area until the application explicitly asks for it. There can be no other way. If you look at Bugtraq, every day, 10-50 PHP applications are broken mercilessly. This cannot continue. Hosters cannot pay the price for the PHP development team’s lack of security expertise.

I wrote back to webappsec that we as security experts should offer our counsel to the PHP Development Team. The only response I received from Yasuo-ã•ã‚“. His response included an exploit of the PHP wrappers (as above) which is completely unaffected by any safe mode implementation. He also suggested I contact Rasmus Lerdorf, one of PHP’s creators who leads the PHP development team.

I e-mailed Rasmus, and although it’s the new year, I have yet to receive a reply. I get a lot of e-mail, but I make an effort to reply to all of it. I wish others would do the same – it is only polite. [ Edit: 24/1/2006 – I have a reply from Rasmus. Apparently, he saw Chris’s blog and thus this rant, and replied. ]

It is time to stop complaining. The time for forgiving PHP’s weaknesses are over – it must stop, and stop now. PHP 6.0 is still in development, and it should be so clearly more secure than anything before it, that hosters will upgrade to it, in the same way they have not upgraded to PHP 5.0.

It is time to ã„ãŸã—ã¾ã™ã€‚

Comments

8 responses to “PHP Insecurity: Failure of Leadership”

April 18, 2007

Mark

Thank You
October 10, 2007

Loler

You are joking right?
It seems you are not able to use PHP in the correct way. Why should a language force you to do some things in a specific way? Its up to you to code right, and decide what is right in your case.
Sure there had been failures what PHP provided. But you shouldn’t forget that PHP enabled people to start coding.
Its normal that beginners may write insecure code, I can write dumb ass insecure code on every language I use when I am a beginner.
So stop your clueless ranting and put some facts on the table that are not just theoretical or searching for some worse examples in a flood of applications.
October 11, 2007

vanderaj

Loler,

I do this stuff as my day job, and so it is as factual as I can make it without breaking NDAs. I review nearly a hundred applications every year. Sometime, I find lots of stuff, others not so much. I’ve only done a few PHP reviews this year because our commercial customers stay away from it with good reason.

The first PHP review this year was so bad, the report weighed in at over 80 pages (most of our reports are in the 30-40 page mark). I know that the customer was unprepared for our findings, and in fact, as far as I’m aware, they’ve made no serious effort to fix the issues we identified.

It comes down to two things:

a) PHP is simple to use. So many people use it
b) the folks who are not CS majors do not even know what security is, and therefore the language designers have a responsibility to code to their primary audience. In PHP’s case, it’s hobbyist and first time programmers.

The skilled programmer like you and me: we don’t count. We are in the upper part of the bell curve. We can take care of ourselves regardless of how good or bad a language and its features are.

A good systems language is a balance between power and security. For example, it’s possible to write insecure Perl but there is SO much pressure to use things like taint mode and DBI’s prepared statements, that pretty much all the Perl I see is heavily standardized, heavily commented, and pretty secure. That’s one way a language which is heavily used in systems contexts, despite its many potential issues, is generally safe. Perl programmers are in my experience no better or worse than any other programmer.

PHP has no such pressure. After coding in PHP since 2002 and still fixing up code five years later, PHP has so much to learn from security folks it’s not funny.

Personally, although I applaud the decision to finally kill PHP 4, it’s far too late. PHP 4 will be on hosters until it becomes too expensive to host PHP any more from the sheer number of sites compromised. PHP 5 did not take off as fast as it should because it wasn’t backwards compatible. I STILL to this day cannot stop support for PHP 4, even though it’s got approximately 10 weeks to live.

I can’t guarantee MySQLi support, let alone PDO with MySQL support. I still don’t have guaranteed access to transactions. Therefore, I can’t leverage those technologies without writing three versions:

PHP 4 only, functional mysql
PHP 4/5, functional / OO hybrid using mysqli
PHP 5, OO mostly, functional a little, with PDO and transactions on InnoDB (maybe)

The last category, PHP 5 with PDO and with transactional support is such a tiny fraction of the PHP install base, that it is not worth writing to that platform. I would be better off writing a .NET on Mono as it nearly has as large an install base as PHP 5 with PDO and transactions.

PHP is a toy language used for non-toy functions. It needs to die as it CANNOT be made safe in its current form considering its core audience.

Andrew
December 27, 2007

Michelle

G’day,
I hope this reaches you and it is probably an ass about way of doing it, but…I am an Aussie gal who just registered as a member of Aussie Vee Dubbers but can’t complete it as I am having a problem downloading UltimaBB so as to enter the forum. It says either server can’t url or contact the host, so here I am.
Email with any help or updates… your baby pics are beautiful!!!!
Now to just gat my baby Kombi Camper into community
Cheers,
Michelle
May 30, 2008

Security And Caffeine

[…] It’s fact, it happens; I would venture that it’s the point of PHP. Now, PHP is often regarded as insecure, but, as many php professionals will argue, this is a failure of novice developers, not the […]
July 19, 2011

qwerty

Have any of these issue been seriously addressed since this was written?
July 19, 2011

vanderaj

No idea. I’ve not really been in that space for a long while.
December 15, 2023

PHP Security: Dumb Users or Dumb APIs? — SitePoint

[…] There’s another round of “Is PHP Secure?” debate happening right now. Chris drew attention to it, pointing to a post by Andrew van der Stock (who’s a contributor to OWASP): PHP Insecurity: Failure of Leadership. […]