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."

YAY

I for one would like to thank him for the nominal increase in success rates of attacks thanks to him!

GREAT IDEA!!!!

Couple thoughts

First, the language is wide open for editing. It might help to be someone who not only finds bugs but fixes them.

Second, it's PHP. Add another API or something.

PHP Security Expert

PHP Security Expert...

Isn't that an oxymoron?

Re:Uh-huh, riiiiiiiiight...

There was an exploit for mambo some time ago, sql injection i believe, perhaps several others also, so mambo is a likely culprit.
One cannot say it was PHP directly that got the machine compromised. It was an exploit in a script written in PHP.
A box isn't going to get compromised if PHP was installed alone on the box without any scripts (at least it's very very unlikely).
Is C the direct cause of your box owned when their is an exploit in say, proftpd for example?

I mean, I could also say...
"yeah, you'd have to be mad to run sendmail on a box you don't want to get owned"
"yeah, you'd have to be mad to run proftpd on a box you don't want to get owned"
"yeah, you'd have to be mad to run bind on a box you don't want to get owned"
"yeah, you'd have to be mad to run a linux kernel on a box you don't want to get owned"

These applications have all had their problems in the past, maybe some still have problems, but overall
they get fixed when new exploits/bugs are discovered.

I'm not quite sure why, but a lot of people/webmasters/admins do not check for updates to the 3rd party php scripts
they have installed, they just install them once and leave them running... Then they wonder why their box was compromised
due to them running out of date software.
You wouldn't leave your windows machine unpatched and never check for updates, would you?

On second thought...

On second thought I would have to agree that the majority of PHP flaws are due to unskilled programming.

just have a look [milw0rm.com]

Re:Question from a .NET developer trying to go OSS

There sure are better alternatives to PHP in the OSS sector! PHP IMHO is a nice toy but nothing I would use in a commercial project.

A soon to be totally OS sollution is of course JAVA with Apache and Servlets/JSP. Just take a look at Sun's website, they have a lot of information, examples and tutorials available. Also, Java is totally plattform independent and easily installed on Windows, if that remains your development system.

Another, more recent sollution would be Ruby on Rails [rubyonrails.org], which has some realy niffty features.

And no, not a dumb question at all! One hint: If you got the time, just download the OSS you are considering ang play around with it, that's probably more usefull than my dumb answer. ;-)

Re:Question from a .NET developer trying to go OSS

Another, more recent sollution [sic] would be Ruby on Rails, which has some realy niffty [sic] features.

Rails is pretty cute. An more functional (but less "shiny") alternative is Catalyst [catalystframework.org]. It's written in Perl, which means you get the benefit of over 10,000 extension libraries from the CPAN [cpan.org] to draw upon. Perl also has some nice features that Ruby or PHP lack, like full native unicode support and automatic taint checking. It's also faster, because it's had 10 years to mature. Sadly people seem to be ignoring Perl these days, but with recent improvements it's nearly as cool as Ruby (check out "Moose").

Also, if you'd like to access a database with compound primary keys, ActiveRecord won't support that, but Catalyst's ORM (DBIx::Class) supports it fine.

Rails is good for quick apps like a wiki or a blog, but for more complicated internal applications, Catalyst is where it's at. Stop by the website, check out our advent calendar [catalystframework.org], or perhaps try the tutorial [cpan.org]. Join us in #catalyst on irc.perl.org if you have any questions!

Re:Question from a .NET developer trying to go OSS

> Bullshit

As the linked article said, this is an experimental patch + hack. With DBIC, you just do find({key1 => $val1, key2 => $val2}), which is a natural extension of the simple single-key case: find({key1 => $val1}). This all works very well in practice, as opposed to the it-might-work approach of ActiveRecord. I'm not saying you shouldn't use ActiveRecord... but I wouldn't use it.

> I am hesitant to try any framework whose partisans routinely bash other frameworks.

Bashing? I said it was good. There are some places where Catalyst is better, and some places where it's not as good. In my experience, Catalyst's good points make more complex applications easier (frontend to an HR system is what I've done), whereas Rails full-stack approach is great for CRUD applications. You're allowed to like both, ya know!

> I'm used to getting this from Python; it's refreshing to see a Perl guy screaming at the wind.

These people (I'm one of them) get upset because their languages are technically better than the alternatives, but "nobody" uses them, and they're shunned for not using PHP. "Perl is so 1996, man, use PHP or Ruby now." Irritating. use Perl; ;)

Re:Question from a .NET developer trying to go OSS

Yeah, with Java becoming open source, its right in line for you. Learning Java as a C# programmer is a joke, the basics are 95% the same, especialy if you use java faces (though I'm a bit "meh" about that).

You pull java with eclipse, apache, strut/spring/hibernate/junit, then pull any database that hibernate supports, and you're in business.

There's a learning curve, but you won't feel like anything is missing from .NET, really (I'm primarly a C# programmer myself, so I know where you're coming from). Unless you had a MSDN Universal license with Visual Studio Team Foundation, or were already using .NET 3.0 (Workflow, Communication, etc), this might actualy give you a lot more power than what you are used to.

PHP reminds me of IIS4

We have a large group of students, staff, and faculty that all have varying degrees of write access to a departmental Apache web server. Every few weeks someone asks why we're not giving people PHP access. Users love PHP because it's so easy; it makes them feel like they're clever programmers. But it seems like security knowledge is never imparted alongside the PHP training. People seem to think it's as benign as plain old HTML. When they ask for PHP I tell them we have a policy about not giving scripting-level access to users without good justification, and they have no idea why that applies to them since "we don't want to do any scripting; we just want to make PHP web pages".

But even leaving all that aside - it seems like every SANS newsletter has multiple announcements either about a bug in some popular bit of PHP-based software, or else in PHP in general. Until that changes, we're sticking to Perl and Python. It's funny, in a way, since the first time I saw PHP I immediately thought of the days when I was writing Active Server Pages on IIS4, because structurally it is so similar - and now we all realize the similarities on the security side (or lack thereof) as well.

Open source is the issue

It's widely acknowledged that open source programs are inherently insecure. Whether the cause is the availability of the "internal blueprints", the free-for-all repository commit access, or the rampant theft of patents, one wonders. By contrast, Microsoft's .NET platform, including the widely praised C#, doesn't have this problem. The guarding of the internal source code, the standards-adhering developers, and the rock-solid legality of its software patents gives Microsoft an advantage versus the haphazard "open source" languages like PHP and Java. One wonders if this is a harbinger of future defections in the open source language camp. Speaking as a patent lawyer, I advise all developers to switch to .NET and Microsoft's enterprise-class C#.

Actual announcement

Here's the announcement from the source himself, via his blog [php-security.org]. Based on that post I'd say he sounds pretty disgruntled with how his efforts towards security were received i.e. "he PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the security of PHP itself you become persona non grata"

XSS by default

When I looked at Zend's introduction to PHP, the first sample PHP program was Hello World, and the second was a cross-site scripting vulnerability. Right, I'm going to trust these people.

As a PHP user....

As a PHP user, I have attempted to better the thing by reporting what I think are bugs. I can't name a single one that wasn't closed with a WONTFIX and a terse, non-thankful "that is a feature, not a bug." I honestly have zero disbelief that those same programmers would turn against Esser when he blamed the language, not the user, for the security problem.

In particular, the late static binding issue (if B extends A then A::staticFunc() ran as B::staticFunc() is ran under class A not B). It's like how it took MySQL took a decade to get stored procedures and views despite many people asking for it. Many people complain about the late static binding issue but last I knew it was still "it's a feature, not a bug."

Regardless, thanks for your work Mr. Esser...

Re:As a PHP user....

non-thankful "that is a feature, not a bug."

Oh boy...Microsoft bought out PHP...

PHP ought to be forked

Someone should fork PHP and do a major rewrite. Drop features like HTML embedding, introduce properly defined packages and make all functionality available in both procedural and OO fashions. Clean up the function names so they're predictable. And make some of the more dangerous functions safer.
PHP could be turned into a decent general purpose scripting language if someone would fork it. Unfortunately that means that we'd need someone who knows the codebase, has time and is fed up with the current PHP development process. Maybe we could talk Esser into it...

Re:As a PHP user....

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.

he just left a mailing list...

The "news" is that Stefan Esser unsubscribed from the [e-mail] mailing list.

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/ [hardened-php.net]
[2] http://www.hardened-php.net/suhosin.127.html [hardened-php.net]
[3] http://www.suraski.net/blog/index.php?/archives/15 -Stefan-Esser-quits-securityphp.net.html [suraski.net]

Love the 'inexperienced programmers' excuse..

Wow, stunningly insightful response "that's caused by inexperienced programmers". He's a clue: it doesn't matter what the origin of the problem is (other than to fix it longterm) - IT STILL NEEDS ADDRESSING. I got news for you: the concept of covering large security related cracks in code with prime bullshit is probably already patented by Microsoft.

Personally I would wonder if Essers' 'abrasive style' is not a result rather than a reason for not being listened to and if this flags up a major problem in the way PHP is coded and maintained I'm all for this move. There is no excuse for sloppiness.

So, the reaction discloses the attitude - seems Esser made the right move..

Not up-to-date on PHP security . . .

can someone explain how it is that the apperently consensus is that PHP is insecure by design, asside from just poor programming? Thank you.

Re:Not up-to-date on PHP security . . .

One of the biggest 'problems' is the way PHP is generally executed as an apache module. You get a lot of shared webhosts that run php as a module, and so the apache user runs the code. Fine, except that if you want to give your PHP script access to your data, you're effectively giving it access to everyone else's data too. So features like open_basedir were added to restrict this.

Then there is features like safe_mode that turns off many system functions that an attacker could use to get round the other restrictions, and register_globals which is a feature designed to work around an inherently insecure system of passing variables to php pages.

and so on, and so forth.. possibly the biggest problem is the ease of coding it, the barrier to entry is so low you will attract coders who (to be polite) don't know as much as they could about programming. So you get a lot of PHP code that is poor quality, makes too many assumptions on things that they should have tightened up (eg, not initialising variables to prevent an attacker from passing them in with their desired values), or checking input to functions from the form or url.

Its the same issue as VB - it was so easy to code VB apps, my boss could do it. So he did. And they looked, performed and crashed as if a manager had coded them :(

Re:Not up-to-date on PHP security . . .

I actually do a bunch of security consulting for PHP based stuff. A great deal of the issues stems from the very beginning of the PHP language itself. Being designed to be as easy as possible without regard to security has kind of made it the Microsoft of scripting langages. They have not built on insecure code, but rather entire concepts that are inherently insecure (fopen() wrappers that open nearly every data connection they're fed, register globals, SQL string concatenation) and have even for a long time endorsed and taught users those concept.

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 [hardened-php.net]) that are/were essentially a WONTFIX. No wonder Essner is getting frustrated.

Re:Not up-to-date on PHP security . . .

I've written lots of PHP code [sf.net] in my spare time, and have written an article [kuliukas.com] on creating "rootkits" to covertly inject into PHP scripts (phpBB2 in particular), so I thought I'd chime in. This'll probably be a long post but hopefully it'll give people some things to look out for.

Here are the most common security problems you run into in PHP:

• magic_quotes: This adds slashes to all input so that you don't have to sanitize it before it gets inserted into SQL. The problem is that developers write their code with magic_quotes on, but don't realize that it's often turned off elsewhere, which leads to gaping holes.
• register_globals: Variables can be placed directly into the global namespace. If you don't explicitly set all variables before using them anything can be injected into them, which brings me on to:
• Only critical errors are reported: If you use a variable which isn't set it'll just return null, with no error (unless you specifically turn up the error_reporting level). This means that someone who isn't familiar with the problem won't know that a variable in their script can be written to by anyone until it's being exploited, functions which you would expect to return an error and halt the script if they fail can carry on without giving any indication of failure.
• fopen_urls: By default you can include scripts hosted on other websites! This often makes remote PHP execution, which would otherwise require eval(), much easier.
  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.)
• Inconsistencies: What one function does can never be applied to what another function does; you can never assume anything with the PHP library and always have to keep a browser window with the PHP manual handy. Using a function without carefully reading up what it does, even when it's very similar to another function you're familiar with, is asking for trouble in PHP.
  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 ..."), null == 0 == "" == false, "a" == 4 == true; generally you just have to be on your toes.
• Input checking is difficult: Do you want htmlentities() or htmlspecialchars() ? Have you remembered to strip_slashes() if magic_quotes is on? Remember the user can input arrays too, are you checking that the input isn't an array? Have you remembered to escape queries with mysql_real_escape_string() ? mysql_escape_string() doesn't account for the character set being used, and so isn't good enough, trying to escape input for yourself is also dangerous. What about null bytes? Remember that the user can input binary data; PHP allows null bytes, and will add a slash to them, but when you send a string with null bytes to some functions, but not others, the null bytes will be silently dropped leaving only slashes.
  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..

PHP security is a disaster by design

Variables are untyped, so if you do $a + $b, it's not clear what the result might be. Variables do not have to be declared before use, so if I have code like:

$authorized = callAuthFunction();
if(! $authoorized) logoutUser(); // note the misspelling
mysql_query("UPDATE account SET ...."); // you get the idea

Woops! Languages that have a permissive syntax make it easy for bugs to hide. And security flaws are just a particular subset of bugs. At a higher level, we have problems such as widespread use of direct DB access all over the place, instead of some kind of persistence layer, which results in likely SQL mistakes, and even injection attacks if the code isn't using correct pear DB. There's no true filter mechanism in PHP. There's no way to annotate objects as requiring a certain user-in-role. The whole thing is a big mess of C code and third party libraries, and there are good old fashioned C buffer overflow vulnerabilities in those areas too. Wee!

Here's an eye-catcher

>bugs were sometimes not correctly fixed or were re-introduced. This was often not noticed because there was no test-rig for exploits and the idea of having one was categorically rejected.

If that's accurate, and if there wasn't some unimaginable compelling reason, any security person would be unhappy.

Zend guy has a good point

Just because the language is easy is no reason to (attempt) to make it idiot proof. Numerous crappy 'security features' have already been added to the annoyance of decent programmers. Making it more secure by design would only encourage sloppy programming, which already is a big problem.

In related news

Law makers in Texas are debating a bill to enable people to own nuclear weapons and heavy artillery and to remove safety catches from guns.

"All you should need is a great big red button that says 'Fire'" said Congressman Bobby Ewing "Its ridiculous that people are prevented from using these things and having to put up with safety devices it just encourages sloppying thinking"

"By letting people launch nuclear weapons with a big red button we are making sure that everyone is aware of how to properly care for their nuclear weapon and that it is their god given right and responsibility to fire it carefully" said some bloke in a hat "I'm fed up with all the ridiculous procedures I have to go through to fire a gun, let alone blow up France just because a few bleeding heart liberals feel they need to protect stupid people in New Hampshire"

In related new Iowa has banned the use of indicators, roll cages, air bags, crumple zones and seatbelts as it gives people too much sense of security. California has banned the use of door and window locks and the use of burglar alarms as they make houses "secure by design".

Secure by design is the only type of security that really counts.

No bad dogs, only bad owners

A bad worker blames their tools and a bad boss blames their workers.

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) ..... 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?

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".

If he returns to the PHP after discussions

Would a suitable headline be "Goaded, Esser Back"?

Apologies to Douglas R. Hofstadter

If PGP...

If PGP stands for 'Pretty Good Privacy', I wonder if PHP should really stand for 'Pretty Hopeless Privacy'...

If people used my butt to the extent they use php

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.

Maybe he wants to become famous?

So I read the piece from his blog and the heise article, I didn't see any remorse against Stefan from the PHP group. I can see Stefan making that accusation, though. It can be very difficult to fix bugs, and sometimes it can take a very long time. So - with the information I got thus far - I think Stefan is trolling and tries to get some publicity. That seems also be the reason why he wants to do a month of PHP bugs.

Movement against PHP

Reading all the comments about PHP throughout the years, I think it's about time that Slashdotters unite against PHP(and Microsoft and...add whatever it is that Slashdotters hate).

I think the functionality of the language is it's biggest enemy when it comes to security. If the language is simple enough like for instance you can only make programs that can print out "Hello world" then it can be considered very secure. It's maybe not very useful, but very secure.
I know programmers who should never be allowed to program in anything but Java or C# and then only simple code.
   

PHP == Bloat?

Is it only me who thinks that PHP after version 2 started getting so much weight and bloat that I would believe anything about how insecure it had become.

Rate new features/functions added to PHP at times seems to be exponential. Something that points to poor project management: it looks like incapable of handling the exploded PHP popularity and attention it gathered.

Though my opinion might be outdated: I was programming PHP last time when version 3 was getting its first releases.

Easy way to make PHP more secure...

Actually get some friggen types implemented! Then, half the SQL injection flaws that are in PHP scripts would become null.

If not PHP, then what?

Ok it's obvious that seasoned coders have a distaste for PHP. But what would the recomendation be for someone who's about to embark on several web projects, and thought PHP / MYSQL was the answer? I'm 100 pages deep in my 2nd PHP book and you guys just scared the **** out of me... I'm ready to hit the book store tonight and start a new approach, but where to start? Assuming I take the Perl route, what books would you recommend to take me from a novice to a worthy code writer?

PHP is the best!

Being simple is good.
we just need a powerful tool to get job done!
there is no need to use a full-featured and mysterious "Real" programming language like Java , only for webs!. it's like shooting mosquito with missiles.
security is an everyday issue... see windows, a multi-billion program that still has security holes.

PHP , popular ,powerful, handy, everythere! use it, improve it, dont judge it!(critics shall only go make their own prefect language).

Main cause of insecure PHP software

From my experience the main cause of insecure PHP software is developers not turning the error validation to the highest during development, so when an unsuspecting user downloads the software little do they know that their system can and often is wide open to stupid bugs and security problems. When you leave error_reporting to the default setting you miss lots of important details, like array keys being passed as constants, variables being referenced before they're created (especially with arrays), incorrect return types, etc, etc, yet people wonder why their code is so buggy? I was installing vtiger, which is a pretty comprehensive CRM that has lots of potential to hit it big, the other night for a client and was slamming my had against the wall at the sheer number of stupid syntax bugs that were in the system.

How many programs out there tell you to turn on the old register_globals that everyone knew was a huge security problem?

How many programs tell you to turn down the error_reporting level to hide their development incompetence?

I was actually considering starting a movement to have the PHP community clean up their act, we'll see if its still needed after the dust settles from this.

Personally I think that with PHP 5.2 they should have stopped supporting deprecated coding practices, like accepting invalid variables and invalid array keys, so that this stupidity could finally stop.

That's why I don't do much with PHP anymore, a large portion of the open source projects that clients want you to "make work" are riddled with utterly stupid mistakes that you spend days if not weeks cleaning it up before you can actually start doing any work.

Damien

PHP & Bikes

My son fell off his bike and skinned his knee, so I bought him knee pads. Then he fell off his bike again and skinned his elbow, so I bought him elbow pads. He fell off and got a rock in his hand, so I bought him gloves and wrist guards. He then fell over in the park and got a goose-egg, so I bought him a helmet. Then he ran into a tree so I bought him a suit of body armor.

Now he has so much protection that he couldn't possibly hurt himself right?

What's that you say??? Give him lessons on how to ride his bike? Holy shit! I never thought of that!

To all those who say that PHP is weak because it doesn't protect the developer... I say you don't understand PHP or development very well at all.

Zend's ZActiveRecord Boondoggle

[I posted this earlier in the context of PostgreSQL Slammed by PHP Creator [slashdot.org], but it bears repeating, since the charlitans at Zend still haven't addressed the problem, and NEVER WILL. Would anyone from Zend please finally comment, and explain just how PHP's plan for a database solution is better and more secure than Python's SQLAlchemy [sqlalchemy.org]? -Don]

The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".

It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs [wikipedia.org], which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.

PHP references [php.net] were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. The [php.net] sloppy [php.net] implementation [php.net] caused [php.net] many [php.net] bugs [php.net] that [php.net] CORE [php.net] DUMP [php.net] PHP [php.net]! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.

PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C se

"PHP has been implemented in a very unsafe way"

The article says:

It is not the case, however, that the PHP project is trying to conceal the fact that PHP has been implemented in a very unsafe way.

Parse that carefully. It says the PHP project is not trying to conceal the fact. What fact? The fact that PHP has been implemented in a very unsafe way.

Oh, that fact. Yes, it's a pesky little fact, indeed. But the fact that they're arguing about whether or not they're trying to conceal it, instead of arguing about how to best address that inconvenient little truth, is a big problem.

PHP's implementation is unsafe, fundamentally flawed, insecure, and it's badly designed to its very core. That's a fact. Any apologist who counters "but it gets the job done" is ignorant of PHP's problems, and ignoring the fact that there are many other open source languages out there that are much better designed, also get the job done, are at least as easy to learn and use as PHP, without all the bugs and security holes, and with many important advantages.

There's no reason to be using PHP to write new software, except ignorance of other languages and refusal to learn.

-Don

those who stand behind their work, those who don't

Perhaps some of us need to add a line to our license blurb at the top of the source file (not the license itself) stating that: "The author of this code stands behind his/her work and will immediately publish any defect reported in this code" while others can place the line "The author of this code does *not* stand behind his/her work and will *not* publish any defect reported until a very long time after a solution is found, if the code can be fixed at all."

Such animosity against PHP!

I understand some of it. It's not my favorite language, by far, and it is easy to shoot yourself in the foot with it.

I'm guessing most who bash PHP as a "horrible" programming language have ever been exposed to true crawling horrors like COBOL and RPG. At least PHP has functions with local variables.

Re:php is the best language still

Huge problem is "default" installs - everyone knows where your sample scripts are. Delete those first thing then move/rename the active libraries.

Now, where's that Ruby book?

Re:Lemme guess... MySQL is also the best database?

Any language is only as good as the programmer using it.

I use a LAMP stack for the most part, many of the security holes in php aren't due to the language itself but the developers of the various webapps.

That being said, this requires a repost of the ol Adminspotting [adminspotting.org] thang.

Choose no life. Choose no career. Choose no family.
Choose a fucking big computer, choose disk arrays the
size of washing machines, modem racks, CD-ROM writers,
and electrical coffee makers. Choose no sleep, high
caffeine and mental insurance. Choose no friends.
Choose black jeans and matching combat boots. Choose
chairs for your office in a range of fucking fabrics.
Choose SMTP and wondering why the fuck you are logged
on on a sunday morning. Choose sitting in that swivel
chair looking at mind-numbing, spirit-crushing web sites,
stuffing fucking junk food into your mouth. Choose
rotting away at the end of it all, pishing your last in
some miserable newsgroup, nothing more than an
embarassment to the selfish, fucked up lusers Gates
spawned to replace the computer-literate.

Choose your future.
Choose to sysadmin.

Re:Lemme guess... MySQL is also the best database?

Yes, bad developers produce insecure code, but let me take you on a brief trip down memory lane.

Way back when, when the Web was new, and CGI was just starting out, there was some debate as to whether C or Perl should be the language of choice for writing CGI scripts. In the end, Perl became much more widely used because it was just too damn easy to open up major security holes writing in C, because it lacked some of the features of Perl (like making it impossible to commit a buffer overrun, for example). Perl won out in early CGI precisely because a lot of the problems of CGI security were already solved because of inherent features of the language.

Now, PHP came along and billed itself (and in fact was designed) as an easy way to make secure web scripts. So, if the PHP code has bugs that impact its security in web-based applications, these things should be addressed. Otherwise, it's going to end up being supplanted by another language that is more secure and easier to use to build web apps.

Blaming the developer for security is only going to take you so far when the language the developer is using is supposed to be SPECIFICALLY DESIGNED for web applications.

Shenanigans!

Now, PHP came along and billed itself (and in fact was designed)

I call shenanigans! No way was PHP 'designed'!

Re:Lemme guess... MySQL is also the best database?

I don't think PHP was designed as an easy way to make secure web scripts. Maybe easy, but certainly not secure.

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.

Re:Lemme guess... MySQL is also the best database?

The classic example is the database access API (or maybe it's specific to mysql, I forgot). It doesn't support bound parameters.

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.

Re:Lemme guess... MySQL is also the best database?

Any language is only as good as the programmer using it.

I actually have a philosophy when writing applications that is almost the complete opposite of that.

Anytime the tool does something that the user doesn't want it's a bug.

This applies to applications, programming languages, heck even cars if you want.

The fact is that if the user gets something they didn't want, no matter how stupidly they tried to use it, the tool still bears some of the blame. I don't care how dumb a thing the user did, there was something there that made them think they could do that and it's a bug.

With programming languages if the language allows the user to create a security hole it's the fault of the language on some level. Sure you can get stupid programmers but blaming the programmer entirely discourages the search for a better language. Yeah if I overrun my array in C it's my fault. But can it be entirely my fault when in Java that same bug wouldn't be a security exploit? Hey, if I drive my car straight off a cliff, is that my fault? Yeah. But a car with a computer failsafe driver wouldn't of gone off the cliff (hey, if two jetliners are on a collision course the computer takes over).

You can never make the perfect tool, even a big green button that will do everything you ever wanted will still have a bunch of people who didn't think to push the button. But it forces you to realize, you can never fix users but you can always fix your code.

Re:Lemme guess... MySQL is also the best database?

It certainly won't work for [...] programming languages

Yes it does. It's a question of design, the design of the programming language, of its documentations and of its library can make security holes much harder to create.

When it actually becomes harder to do the wrong thing than to do the "right" thing, creating security holes becomes the fault of the user. When it's much harder to do the "right" thing than the "wrong" one, and most documentations suggest the "wrong" thing, then it's completely the fault of the language.

Most PHP issues are the latter.

Re:Php weirdness

Of course he's using echo wrong, that's the whole point. I assume the question is, why is it outputting "42311" and not "42131"?

Re:php certainly is the best language...

Only on /. would that get modded "Insightful"...

Re:Chinese go for PHP, renounce Ruby/Rails

A simple reason: ruby was laid out by a japanese... it's a fact..

You mean Chinese base their choice of programming languages on racial prejudice instead of technological merit??!

Speak for yourself! All Chinese can't be that stupid. But at least now we know the real reason you're so fixated on PHP and refuse to consider the alternatives.

So do you think Nazi Germans should hate PHP because it was "laid out" by a Jew? Do you refuse to use Python because you hate the Dutch?

-Don

Re:Java made easier

you don't need a whole freaking J2EE stack to do web programming in java, it's really easy to get a tomcat installation setup and write some jsps.

J2EE is a huge specification, but nothing requires you to use all of it.