Slashdot Mirror
PHP Security Expert Resigns
juct writes "PHP security holes have a name — quite often it was Stefan Esser who found and reported them. Now Esser has quit the PHP security team. He feels that his attempt to make PHP safer "from the inside" is futile. Basic security issues are not addressed sufficiently by the developers. Zeev Suraski, Zend's CTO of course disagrees and urges Stefan to work with the PHP development team instead of working against it. But given the number of remote code execution holes in PHP apps this year, Esser might have a point. And he plans to continue his quest for security holes in PHP. Only that from now on, he will publish them after reasonable time — regardless if a patch is available or not."
Update: 10/30 12:57 GMT by KD : Zeev Suraski wrote in to protest: "I'm quoted as if I 'point fingers at inexperienced developers,' and of course, there's no link to that — because it's not true! The two issues — security problems in Web apps written in PHP, and security problems in PHP itself — are two distinct issues. Nobody, including myself, is saying that there are no security problems in PHP — not unlike pretty much any other piece of software. Nobody, I think, argues the fact that there have been many more security problems at the application level, then there were at the language level. I never replied to Stefan's accusations of security problems in PHP saying 'that's bull, it's all the developers' fault,' and I have no intention to do it in the future."
Very true. My company just won a large contract to convert an app from a LAMP stack to a .NET 2.0/SQL 2k5 stack.
.NET stack compared to LAMP, as well as the fact that we can acheive more TPM then LAMP on the same hardware.
What sold the client was the rock-solid reputation of the
there is a wide choice of languages and platforms.
languages: there's java, there's python, there's perl, and there are more. each of the first three is (IMHO) a lot better than php (as I know it, up to about v. 4) for building web applications.
servers: Apache, with either mod_perl or mod_python access to the APIs is very good. Of course, there's the plenty of java web servers and ways to run those with or without Apache.
platforms: look at the Apache foundation's site for java, perl and python modules.
development environment: I prefer Eclipse, but there are a few to choose from.
Good luck,
The "news" is that Stefan Esser unsubscribed from the security@php.net mailing list.
5 -Stefan-Esser-quits-securityphp.net.html
Stefan Esser will continue to work on PHP security through maintaining the Hardened PHP project [1] which is a patchset to PHP which enables some low level security features into the language, as well as the suhosin extension [2] for PHP which can be used without patching PHP and "protects servers and users from known and unknown flaws in PHP applications and the PHP core".
I am personally of the "full disclosure" security mindset, so if there was indeed an issue with the response time of the "PHP Security Response Team" then some outside pressure would be a good thing.
More about this on Zeev's blog [3].
[1] http://www.hardened-php.net/
[2] http://www.hardened-php.net/suhosin.127.html
[3] http://www.suraski.net/blog/index.php?/archives/1
Perhaps I'm the only one that noticed, but I'm quite sure the parent was being sarcastic.
A bad worker blames their tools and a bad boss blames their workers.
..... then trips you up with anotherobviouslynamedfunction($par2, $par1). You could say it's not all PHP's fault, as the functions originate from different shared libraries, and PHP is only providing an interface to them by their original name and with something like their original syntax. But it still smacks of laziness on the PHP developers' part. Short aliases for commonly-used functions (a context-sensitive editor can always expand them for the benefit of the anal retentive), and differently-named work-alikes for functions that take their parameters in a different order than you might expect, wouldn't have hurt. Would they?
There's no denying that PHP has things wrong with it. It started out as a bastard son of Perl, tried to be a bit more n00b-friendly and tripped over its own cleverness. The beauty of Perl is its very inconsistency. The functions you use most have the shortest names, and there is no need to clutter things up with unnecessary brackets around arguments. Regular expressions, which you are going to use all the time, have a distinct syntax. Number and string data types can be interchanged with such wild abandon, there have to be separate operators for addition and string concatenation (JavaScript, I'm looking at you). There are constructs to populate arrays quickly. All things are subordinate to the goal of letting a programmer get a job done. Easy things are easy, hard things are possible. Perl is so broad-minded, it even has the Principle of Equivalence built in!
PHP lures you in, with obviously_named_function($par1, $par2)
Still, you've got two choices, I suppose. Learn to put up with the idiosyncracies or learn another language. And never forget the Principle of Equivalence; "All Means to the same End are equally valid", nor its corollary, "Means which are not equally valid serve different Ends".
Je fume. Tu fumes. Nous fûmes!
Bullshit
I am hesitant to try any framework whose partisans routinely bash other frameworks. I'm used to getting this from Python; it's refreshing to see a Perl guy screaming at the wind.
Instead of changing concepts midway through they have added security layers and APIs that need to be *explicitly* set - meaning that like Windows (was?) they have a policy of being open per default and having to be explicitly made secure, instead of closed by default and enabling only what you need.
That's what I think Stefan Esser means when he says "safer from the inside". Many things in PHP are inherently flawed and can only be remedied through changes in concept and nothing else.
Add to that stuff like $GLOBALS overwrite (more details here) that are/were essentially a WONTFIX. No wonder Essner is getting frustrated.
:/- spoon(_).
PHP's niche in the web ecosystem is as "the stupid, easy to host scripting language". If you forked it like that, you'd basically have mod_perl, and everyone would still be using the original, awful PHP.
The classic example is the database access API (or maybe it's specific to mysql, I forgot). It doesn't support bound parameters. Use of placeholders ('?') and bound parameters is a must for secure SQL, but PHP doesn't support them, and instead requires the developer to jump through hoops escaping user-supplied data which must be passed as literals into the SQL statement.
Although it might be possible to make a secure SQL-using PHP script, the odds seem against it. Everytime I look at the changelogs of popular PHP applications, I see new fixes for SQL injection vulnerabilities. Clearly programmers don't always remember to escape those literals!
Lack of placeholders also affects the database's ability to cache prepared statements. Statements full of literals are different each time through the loop, whereas parameterised statements can be executed more quickly.
All in all, PHP strikes me as a toy language and not well suited to writing secure systems.
Amen to that.
I had a fun one where one of my scripts would cause a segmentationfault, after hours of debug I found that they don't check the return from malloc when you call a function, so a very deep recursive function will result in a segfault. Now I had the problem with an actual system with 1000s of lines, so I made the simplest possible:
function foo($a){
echo $a . "\n";
foo($a+1);
}
foo(1);
Now this is of course a stupid function since it will never terminate, but it illustrates the point of the segmentation fault, I don't mind that deep recursive functions can exhaust the memory available, but I do mind the way the system handles the problem.
The bug got rejected, and that was that. I don't do PHP anymore, so I don't really care about that any more.
Here are the most common security problems you run into in PHP:
Who would have thought "<?php include($var.'/include.php'); ?>" will run any PHP on any server, anyhere? (The attack in the article above leveraged entry using this, coupled with register_globals.)
The same goes for just about everything; are you checking whether some input equals some harmless number before passing it on to a SQL query or the browser? Don't forget that (5 == "5 UNION SELECT secret FROM
To check input in PHP you have to be absolutely rigorous and take no half measures, people who aren't aware of the dangers don't stand a chance.
To be honest I'm a big fan of PHP, it's very flexible and lets you develop very quickly and easily; if you have the knowledge and self discipline it's an excellent language. But allowing fast, easy development at the cost of security is insane for a server-side web scripting language!
I was hoping that PHP6 was all about doing a 180 degree turn on security, but this article doesn't bode well..
// MD_Update(&m,buf,j);
Have a look at the PEAR library sometime, specifically MDB2. It does what you're looking for in PHP.
Obviously not, since he said it was embarrassing and now he doesn't do it. Awesome reading comprehension.
It's obviously been a very long time since you've coded in PHP. The native PDO layer in PHP 5 supports bound parameters for all database drivers, and there are numerous other data abstraction layers that support this which have been around even longer.
Just because all these "popular PHP applications" you mention (care to cite examples?) don't follow good programming practice doesn't mean the language itself is flawed. PHP can't force someone to write good code.
magic_quotes register_globals Only critical errors are reported include($var.'/include.php');
The last one should get a fix in PHP 5.2.1 for data-URIs.
Input checking is difficult:
Which of these functions does input checking? None? Maybe http://php.net/ctype would help.
Correct, the semantics of == are different in PHP than in most other C-like languages. The operator you are looking for is ===. As a further note, I usually explicitly cast values to int if expect them to be integers, so random strings just become zero.
Centralization breaks the internet.