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."
The Apache code is also available, and it doesn't have these problems.
Have you noticed how many sever security flaws have been reported in Apache in the last few years?
Here's an exercise. Count the number of severe (or even not severe) flaws in IIS6 over the last 3 years, then compare that number to the number of severe (not even counting non-severe) flaws in Apache in the last year alone. Then compare the number of severe flaws in PHP this year and compare them to the total number of flaws in ASP.NET since it's inception 4 years ago.
Report back your results.
If you need web hosting, you could do worse than here
The file upload exploit wasn't programmer error and this was the biggest cause of site defacements via PHP seen so far.
:)
SQL Injection is the default mode of the PHP paradigm.
PHP is a toy language. It should be drowned in a bucket.
And I've been paid to program in it for longer than I care to remember though it was PHP3 when I started, you work it out
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
my butt would be giving buttloads of major security holes ...
Something which is used extensively gets more flaws discovered than something that is used less. Get this in your heads.
Read radical news here
PHP has security issues??!!!!
Yup, but PHP (still) makes it really easy to open SQL injection holes in your apps, it's therefore some kind of meta-culprit.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
PHP is perfectly secure if configured properly and if run by an admin who knows what he's doing with only scripts by competent authors installed.
Yeah, good luck finding those. I'm sure they exist, but really, it's a lot less work to just not let PHP near your machine, ever.
A book on some other language. Do yourself a favor and get out of the landmine-filled sandbox.
A simple reason: ruby was laid out by a japanese...
it's a fact..
China, in fact, is very fragile.