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."
On second thought I would have to agree that the majority of PHP flaws are due to unskilled programming.
just have a look
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.
#DeleteChrome
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, 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. ;-)
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).
.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.
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
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.
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..
Insert
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.
I stole this Sig
>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.
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.
An Eye for an Eye will make the whole world blind - Gandhi
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
> 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;
My other car is first.
Amazon has The Design of Everyday Things by Don Norman available second hand. He argues similarly. If a door has a sign that says 'push' and someone tries to pull, you can blame the user, but it would be better to design a door that invites pushing and discourages pulling. Or vice versa. abebooks.com also has some copies. It was also published as The Psychology of Everyday Things. Good read.
Loose lips lose spit.
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.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler