Slashdot Mirror
March To Be Month of PHP Bugs
PHP writes "Stefan Esser is the founder of both the Hardened-PHP Project and the PHP Security Response Team (which he recently left). During an interview with SecurityFocus he announced the upcoming Month of PHP bugs initiative in March." Quoting: "We will disclose different types of bugs, mainly buffer overflows or double free (/destruction) vulnerabilities, some only local, but some remotely triggerable... Additionally there are some trivial bypass vulnerabilities in PHP's own protection features... As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed."
Public Holes Publication, isn't it ? ;)
-- Rastignac was here.
Looks like this will also be "Month-of-me-working-harder-to-make-sure-my-site-i s-patched- and-updated-and-not-exploited-by-script-kiddies"
Lindsay Blanton
RadioReference.com
I thought every month was PHP Bugs month?
...there are that much holes in PHP (which i don't doubt), mr. esser seems to be on a kind of crusade since he left the security response team.
month of PCP bugs. i see them all over my skin and i can't scratch them off! SOMEONE HELP ME
I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.
I am actually glad to see one of these xxx month of bugs. Personally I have always thought PHP to be a steaming pile of poorly thought out garbage but there is no denying its popularity despite its flaws. Anything that actually helps the meme 'most php flaws are caused by poor programmers' actually become a reality by improving the core security of the language is therefore to be welcomed.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I recently installed modsecurity http://www.modsecurity.org/ for apache along with the rules from http://www.gotroot.com/ and it's done a good job of blocking attacks on my server including a lot of the php mail() injection attempts, whilst it has shown up a few false positives like someone posting a message with sql keywords e.g. "select" "from", it is certainly worth installing even if you have to monitor the logs for a bit afterwards to watch for the false positives and alter the rules accordingly.
Whilst it probably won't solve a lot of the problems with php and security it does help protect the server especially when you don't have control over what your users are uploading to their web space.
But to me (and I'm not the only one), PHP is a huge security hole. There are people that consider machines running PHP insecure. Mod me down, but it's a fact.
Maybe you shouldn't bother with the patches. If you're running any of the well-known PHP software, there's a good change your server has already been compromised by one or more such script kiddies.
I worked at a somewhat popular web hosting company for a while, and you wouldn't believe how often PHP sites are exploited. Most of the time the site owner had no idea that their site had been compromised in some way, even those who went out of their way to ensure that they were running the latest version of whatever PHP software they were using.
I always had the feeling that the bad security reputation with PHP had less to do with technical bugs and more to do with how easy it is to write insecure code(especially when using the mysql module). Also at fault is the general lack of programming understanding by the amatuers who find their way to PHP because it is so easy to go from having a static HTML page to a dynamic PHP page. Are there a lot of vulnerabilities in the interpreter?
It's amazing, but the PHP team are worse than Microsoft ever were with security.
This is very true. And also very unfortunate. When it comes to many managers, PHP has given the entire open source community a bad name. This is mainly because it has been repeatedly pushed as being part of the LAMP suite, when in fact Python and Perl are far better options for the 'P'. So when you recommend the use of Linux, Apache or MySQL, they automatically think of PHP, and recall how terrible its security is. And then they associate that lack of security with Linux, Apache and MySQL, even when that's not the case!
If there's one thing the open source community as a whole should do, it should be to disown PHP. Responsible open source developers and projects need to just stop using it for their web sites. It'd be good if more things like this Month of PHP Bugs were held, just to show the public that the OSS community knows that PHP is terrible, and wants to do something about it. The longer we continue to use PHP, the harder it will be to repair the reputation of even completely unrelated (and far more secure) open source projects.
Only a month?
Ha ha, yes, thank you, I'll be here all week, bringing predictable yet mildly amusing banter. In fact, I'll be here all year. The whole of my life, probably. *breaks down and cries*
Whence? Hence. Whither? Thither.
If he really wants to make a difference, he should fork PHP and really fix up the language and interpreter to his liking. Besides bug and security fixes, a standard naming convention for built-in functions would be quite nice. Maybe Esser could do for PHP what EGCS did for GCCS if he did that.
Not to start a little argument over PHP and Python, but you're comparing apples with oranges here. You are saying that PHP is insecure, its semantics are undesirable and so are its standard libraries, database interfacing, interpreter and performance, and then you come along saying how awesome Django is, disregarding that actually you're comparing a language with a framework.
There are a handful of decent PHP frameworks out there, with others coming along, which you can take and compare with Django, but please don't bash the language because you don't like its semantics, you have something personal with it or you didn't take the time to choose a decent framework.
Regarding the database interfacing support, I beg to differ, I believe PHP has been supporting a large number of databases for a longer while than most of the other web scripting languages out there today.
This is not your signature.
Do we need a month dedicated to every application that has bugs in it? Because I'm pretty sure our sun will have imploded by then.
The bright side, it seems to me, is that PHP's openness means even if the developers are slack, the bugs can still be disclosed without IP litigation threats.
Also, he's given the developers a week or two of warning before March. If there's anything *that* serious in there, actually known to the developers, the fix could conceivably be ready by the time the bug is announced.
I run PHP sites, and I'd rather see the bugs public and being patched, than known only to the developers (we hope).
Disregard that post, I should have previewed and read it again before submitting. It actually makes it sound like PHP is the OpenBSD of scripting languages, which is obviously the opposite of the desired effect.
Fork PHP. This is what they should do.
/. security image is the word "toasted". Haha nice!
Do not let it execute inside web pages. X server pages is bad. Take PHP outside of web pages altogether. Good PHP programmers should be using Smarty templates anyways.
Make a good VM for PHP and clean up all the damn bugs. PHP has nice C/Perl syntax, it has the potential for a good general purpose language.
Create a "pervlet" container. No, not for perverts, but to serve PHP web objects much like Tomcat for servlets. Don't stuff everything inside Apache. Leave the front gate for security configurations and static pages.
That's it for now. Thank you and come again.
P.S The
I've been running Gallery (& more recently Gallery2) and Serendipity on a server (recently updated to 5.2.1 with Suhosin) for some time now. There have been many posts here about not using PHP, but finding replacements for these applications which don't use PHP is either hard or bloody impossible. Is there a resource site which shows web apps which *don't* use PHP? What languages are better to look out for? Ruby on Rails? Python?
I'm not a programmer and never will be, so "Code your own!" doesn't work for me. If PHP is really so insecure then what are realistic alternatives?
TIA
This stinks of self-promotion. Calling something a "Month of PHP Bugs" does nothing to improve PHP's reputation. It sounds spiteful, in fact.
Yep. Everything he writes on this topic is along the lines of:
-They all suck.
-I'm the greatest.
-They're all out to get me.
-The fools, the laughed at me at the institute.
-You aren't taking me seriously! I've fixed everything in my personal extension to PHP and you keep breaking it by changing the language!
etc... etc...
I don't know what he thinks he's going to accomplish - but he's made his name synonomous with "shit disturber" and while he claims to be trying to make PHP better, he's only poisoning things in the long run.
BlackNova Traders
On a side note, anyone know where I could find that Suhosin extension compiled as a binary (DLL) for windows ?
"Month of Shooting Fish In a Barrel"
At least the Month of Apple Bugs was a hard target to go after.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Scratch harder.
Well, I do not have a lot of experience with PHP (only some typical unsecure LAMP tests) but after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?
.NET was just out) and I can tell you that even there, the microsoft product was better than PHP. One of the things I dislike about PHP and I liked about the WebForms .NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.
I have programmed in PHP and C#/VB.NET for web forms (back when
Ubuntu is an African word meaning 'I can't configure Debian'
Enjoy your stay this month Mr. PHP.
Love,
Artie MacStrawman
after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?
It's a backwards compatibility hack. When they implement mysql_escape_string, the MySQL C API didn't need a connection object to the server to perform quoting, it just did it locally. Some advanced features were added in later MySQL versions, and a connection to the server is now needed in order to know what character set is in use in order for the quoting to be performed correctly. If you're just using us-ascii/iso-8859-1 like most MySQL developers, you can ignore the difference. If you're using UTF8 or some other charset, you need to make sure you use the "_real_" version.
The whole 'mysql_*' API ought to be deprecated anyway. mysqli is much better.
One more thing:
.NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.
One of the things I dislike about PHP and I liked about the WebForms
As somebody who has written a 3-tier web application in PHP for a well-known multinational company, I can assure you that tier separation is not only possible in PHP, it's actually fairly easy. Just don't try forwarding remote session IDs to the middle tier from the front tier and then running them on the same server. It won't work.
Here are a few simple precautions for PHP configuration:
- Do not(!) install cURL. I know it is useful, but has a lot of security problems!
- Disable register globals [default as of 4.2.0]
- Safemode is worthless and a little too restricting, use OpenBaseDir.
- disable_functions = exec,system,passthru,shell_exec,proc_open,proc_cl
o se,proc_terminate,proc_nice,proc_get_status (may be more, off the top of my head :-)
These are what I can think of off the top of my head. This allows full compatability with all major scripts [mostly due to not using SafeMode] but still holds a fair bit of protection from people executing scripts and pushing them to run in the background. Had this happen to me a few years ago. I was hosting someone as a favour, and I'm not sure if they did it, or they were running some crappy code and it was exploited. Either way, their account was suspended.Give people a day or two to respond to each exploit before he hands us another to go racing after.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
I hereby declare March 2007 the March that never ended, in spirit of September that never ended.
My personal opinion is that there are far too many people out there that call themselves Wep Applicaton/PHP security experts and write books/give talks about PHP Security
No, kidding?
So how do you separate code and HTML with PHP?
Just wondering.
Why not a Millennium of PHP bugs? I'm sure there are at least 365,250 bugs in PHP.
I'm going to need enough popcorn to last... March.
Game... blouses.
Have a back end program that doesn't produce any HTML output. Have it produce a data structure that describes the information to be embedded in the page, along with the name of the template to embed the data into. More complex schemes may be necessary for some apps, but this suffices for most. Serialize this data structure (you could use any appropriate data serialization format, I generally use simple XML schemes)
Write a front end program that takes the user's request parameters and parses them, selects an appropriate back end program and then includes its response via file ('http://whatever') (or cURL if you need to POST data). Then it can either do what I do, which is use a template engine to process that data into an HTML page, or if you're feeling too lazy to do it that way you can use PHP itself as the template engine: just include ("../templates/" . $templatename . ".inc") (after suitably validating $templatename of course). The code in the template is very simple, using PHP only for simple variable substitution and iteration over predefined data structures.
If you only need logical and not physical separation of the front and back ends, you can include a file with the implementation of the data-structure producing logic and call that, which should save the cost of serialization and deserialization.
Separation of code and presentation can be done by using a templating system. Smarty is a popular one, although it's often criticized, and there are a lot others around as well. FastTemplate, although old, is also a choice.
Most of the frameworks mentioned above are built fanatically on MVC, so this separation is imperative.
This is not your signature.
If you teach a man to fish with a rod, he won't immediately know a better way to catch more fish. The idea of using a mesh net to catch more fish at once will not be apparent to him -- it will take time. A man and his tools are departed only when he finds something better for the job.
So let's apply this concept to learning in the PHP community. For years, PHP developers (newbies, amateurs, and experts alike) have been handed down wisdom that reflected the current knowledge. Years ago, it was using registered globals. Then it became including pages via the query string. And so on... You can imagine for someone new to PHP how hard it would be (if not impossible) to distinguish right from wrong when everyone was telling you to do a certain thing. Articles, forums -- you name it, they preached it.
PHP has become more insecure due to the amount of bad advice spread, not because of PHP. What did we all learn about pointers? When abused or not taken care of, they can cause problems. The same goes for the tools PHP offers.
Slashdot will forever gouge PHP for being insecure, but I think it has everything to do with an immature community dishing out advice far too soon. PHP has matured, and so has much of the advice. Given more time, bad advice will be harder to find.
Blaming PHP for being insecure / providing insecure tools is like blaming auto manufacturers for attaching a steering wheel and a gas pedal to cars that cause accidents... think about it.
For he today that sheds his blood with me shall be my brother.
In python, there are several ways to write websites with varying degree of complexity. One of the most interesting is Cheetah templating engine http://www.cheetahtemplate.org/
I've long argued that for as much as the pro-PHP group blames the coders, there is simply no excuse for some of the levels of vulnerability. So, while I'm loathe for the torrent of problems, I am glad to see someone finally calling PHP out in the open for some of the problems it created long before any kid touched a single line of code.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
You might want to try http://www.nyphp.org/content/presentations/3templa tes/ - it's a good explanation of how and why you should use templating. Which method you go for is entirely up to you but I recommend not using a template engine unless you're planning on building a large site and using PHPs native ability to template instead.
After learning PHP some years back by reading a couple of books I was satisfied with the level of information I got from it. I was able to write my own web-apps, hoorah! Over time though, common sense kicked in when I realised that merging PHP and a fair amount (not the whole lot) of HTML did nothing for readability and future maintenance. It's worth nothing here that I'd not much experience in formalised programming methods or style at the time.
Let me tell you, as a newcomer to PHP you see plenty of guides and books explaining how to create run-of-the-mill web apps but will never come across anything that tells the benefits of splitting up your code into different layers of logic (or funnily enough, how to use OOP). As I mentioned, common sense kicked in and I spent some time looking into it until I eventually found what I was looking for. This is a clear example of how emphasis is placed on firing out code rather than doing it right.
"At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical."
Maybe. But to take more than 31 bugs and disclose them a day at a time so that in effect major web-facing infrastructure for big business and home users alike will have no chance at all of being secured during this entire window, all for the purposes of publicity?
Really? Leaving aside the matter of using shared libraries, whenever I've had to add features to PHP it's gone like this:
The only actual downtime occurs during step 5, which lasts maybe a second at most. This is Linux after all -- you can run the old version while you're installing the new one.
Or am I misunderstanding your point?
I'm a PHP developer (amongst other things) and am looking forward to this. Stuff like this can only be good. And if it helps to find new or forgotten bugs - all the better.
We suffer more in our imagination than in reality. - Seneca
You will want to use an MVC (Model-View-Controller) paradigm. The Model contains your data work (accessing database, data manipulation, etc.). The Controller directs the application what to do, and the View is the final result (HTML).
The View can contain minimal PHP that's only used for display purposes. No data manipulation is done here (other than walking through records, for example). Alternatively you can use templates, but the point is moot because you're adding a layer of abstraction on top of what PHP already does -- templating.
I recommend CodeIgniter as a simple framework for any future applications you build. It's based around MVC, has a small footprint, and is very easy to learn and work with.
For he today that sheds his blood with me shall be my brother.
This is all in fun, it's his "brand". Didi your last marketing effort end up on CNN? Of course he's picked the low-hanging fruit first. Once it's 2008 and it's the "Month of COBOL on DEC Alpha Bugs" let's see if he can still stir up a media cluster f***. Go Stefan!
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
You wouldn't be using PHP if you weren't an idiot yourself, so shut up with calling other PHP developers idiots, and blaming them for the problem. If you were such a great programmer, you would know better, and you wouldn't be using PHP in the first place.
-Don
Take a look and feel free: http://www.PieMenu.com
Can you please explain why register_globals was there in the first place? The reason is that PHP was designed by idiots, pure and simple. It should have never existed, not as an option, and especially not as a default setting. The same goes for magic_quotes_gpc and its ilk.
Face it: PHP is a horribly designed language from the core to its extremities, and you can't knickle-and-dime security issues as you discover them. The PHP development team's attitude just makes it much much much much worse. You're an idiot to trust them, and a danger to the Internet if you apologize for PHP, make excuses, and continue to evangelize and recruite naive developers.
-Don
Take a look and feel free: http://www.PieMenu.com
And you're surprized? You made your bed, now sleep in it. Or rather, stop sleeping until you've un-installed PHP on all your servers, because it will never be secure, thanks to the PHP team's attitude.
-Don
Take a look and feel free: http://www.PieMenu.com
Are these exploits or "exploits"? After all, a lot of "exploits" are huff and bluff about what really should be called bugs or even just quirks.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
No, Ruby On Rails is quite insecure. The libraries, the interpreter, and most Ruby On Rails software are all poorly written.
And if inexperienced scripters is really the major problem, then the Ruby On Rails developers need to take them into account when developing Ruby On Rails. This means that the Ruby On Rails developers need to add features to their product that help prevent such inexperienced people from writing easily-exploitable scripts. There has been some work done in this area, but it's been minimal, and so far ineffective.
Yes, inexperienced developers probably are responsible for many of the problems. But the more experienced (I would hope) developers of Ruby On Rails itself need to step up to the plate, and do their part to deal with the problem of inexperienced developers writing poor code. Even if they don't do it in order to offer a better product, they should do it to save the few remaining strands of their reputation.
Wow Insightful!!! I feel enlighted. How about perl?
No, Perl is quite insecure. The libraries, the interpreter, and most Perl software are all poorly written.
And if inexperienced scripters is really the major problem, then the Perl developers need to take them into account when developing Perl. This means that the Perl developers need to add features to their product that help prevent such inexperienced people from writing easily-exploitable scripts. There has been some work done in this area, but it's been minimal, and so far ineffective.
Yes, inexperienced developers probably are responsible for many of the problems. But the more experienced (I would hope) developers of Perl itself need to step up to the plate, and do their part to deal with the problem of inexperienced developers writing poor code. Even if they don't do it in order to offer a better product, they should do it to save the few remaining strands of their reputation.
WOW!!! INSIGHTFUl!!! You Mods are so smart!!
What language name shall I insert next?
It's more like a chocolate Advent Calendar of bugs. Script kiddies get a new treat every day, and the rest of us need to wait an extra month for the fat to be trimmed off with full patch.
Effective publicity, yes.
Effective results, no.
But the point, I think, is that it's a lose-lose situation to begin with. I'm not convinced software developers have any "shame" threshold to speak of.
Besides, there are more important and older bugs to tackle, like this tooltip issue I've had in Firefox since 0.9. SOMEONE FIX!!1!
The root cause of the problem of PHP's popularity are the minions of ignorant, irresponsible PHP fan-boys, evangelists and apologists who are always shooting their mouths off trying to convince droves of other sloppy uneducated programmers to use PHP.
STOP EVANGELIZING PHP! YOU ARE HARMING THE INTERNET!
-Don
Take a look and feel free: http://www.PieMenu.com
I think I'll switch to brainfuck.
Anyone ever heard about a bug in brainfuck?
If you're not fearful, uncertain and doubtful about PHP, then you're head is stuck in the ground and you do not know what you're talking about. PHP should most certainly be feared, doubted and not trusted. Stop being such an apologist fan-boy, and trying to attack the messenger instead of the cause of the problem: the PHP development team's negligent attitude.
-Don
Take a look and feel free: http://www.PieMenu.com
Not only is the PHP development team negligent when it comes to dealing with security bugs, but they're incompetent when it comes to understanding the limitations of their own language, the tenants of object oriented programming, and database object-relational mapper design.
Here is quick summary of my previous post about Zend's ZActiveRecord Boondoggle:
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".
To summarize: [Criticism of PHP "references".] [Criticism of PHP "object system".] [Description of "static methods".] [Description of Ruby on Rail's ActiveRecord.] [Description of "ZActiveRecord", Zend's lame half-baked cargo cult attempt to ape ActiveRecord.] [Zend busted for misleading screencast.] [Blog posting that proves: ZActiveRecord Can't Work.] [Zend misunderstood their own language's object system, showed fake code in a screencast that could not possibly work (because of a PHP bug), and made promises of ZActiveRecord they couldn't keep, because of that stupid bug they refused to fix.] [Longstanding bug that PHP static methods that the developers refuse to fix.] [Summary of comments on the bug that prevents anyone from writing an ActiveRecord-like ORM in PHP.] [Final word from andi, calls it expected behavior, demonstrating how he misunderstands object oriented programming, and casually dismisses all the bug report's valid comments.] [Zend gets hoisted on their own pitard by this very bug.]
And here's the final word from andi: "Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ [php.net] and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [php.net] This is expected behavior. self:: binds statically to its class (to the best of my knowledge other languages like C++ don't support this either as they require to explicitly use the class name). There are actually advantages also to this approach as they allow you to protect and encapsulate functinality."
Since Zend's dishonest and embarassing public-relations disaster with the ZActiveRecord Boondoggle, Zend has quietly withdrawn their plans for ZActiveRecord, instead of fixing the stupid bug that made it impossible to implement and ORM like ActiveRecord in PHP.
It's not just security that the PHP developers and Zend don't care about. They also don't care about nor understand object oriented programming, nor database object-relational mapping.
There is absolutely no reason to use PHP, when there are great languages like Python with extremely powerful, easy to use, safe and secure, database independent, object-relational mappers like SQLObject , and intelligent scalable SQL toolkits with multiple modular ORMs like SQLAlchemy. That stuff so blows away PHP's horribly insecure string-concatination approach to SQL, and all of the kludgy PHP database libraries people have cobbled together over the years.
-Don
Take a look and feel free: http://www.PieMenu.com
What's up with this logo: http://www.hardened-php.net/globals-problem
How about putting all the PHP developers on a month long reality show, where if they can't fix all their bugs in a month, they have to cancel PHP!
But there would be so many bugs, soap operas, security holes, personality conflicts, segmentation violations, and hissy fits, that the network executives would extend the PHP Reality Show again and again, and it would end up running longer than The Simpsons. They could keep it going forever, by fixing one bug a day, while adding two more bugs.
-Don
Take a look and feel free: http://www.PieMenu.com
Oh, please. Smarty is a piece of shit. You are hereby sentenced to go read the Smarty source code, and don't come back or post anything else about PHP to slashdot until you are done, and have washed the puke taste out of your mouth. Then you will be so embarassed you mentioned Smarty. It's one of the most truly horrible pieces of PHP code I have ever seen and had the misfortune of having to use. The whole idea is ill-concieved. PHP is ALREADY a templating language: why use it to implement another half-baked watered-down ill-defined templating language, that doesn't even support all the functions or syntax of PHP? I mean, it's not like Smarty keeps you from having to learn PHP, and then you still have to learn its horrible quirky half-assed syntax, which is even worse and messier than PHP! And you certainly can't edit in an XML editor, since it's flagrantly XML non-compliant, or even a PHP editor, since it's not PHP syntax either.
Templating languages should be clean, elegant, well integrated with the native scripting language, not trying to fight against it. And they should be 100% XML compliant, so you can edit and integrate them with all your other XML tools. Python's Kid templating language is a wonderful example of how to do it right.
-Don
Take a look and feel free: http://www.PieMenu.com
The default behavior in case of database problems is to display the host, username and password in the browser? Good grief.
No, I did not read the f***ing article!
Java! And Applescript! And FORTRAN! And Cobol!
It was highly unethical for the PHP development team to sweep all those bugs under the rug. The cat is already out of the bag. They are already public. Making an public issue of the PHP developer's horrible behavior and careless attitude is the only ethical thing to do. Don't blame the messenger. Blame the incompetent people who refused to fix the bugs, not the diligent person who fixed them, but had his changes ignored by the incompetent people.
-Don
Take a look and feel free: http://www.PieMenu.com
If PHP is so great at supporting databases, then why did Zend give up on their ZActiveRecord Boondoggle, which wouldn't work as they falsely advertised because of a stupid PHP bug they refused to fix? Why isn't there anything like ActiveRecord for PHP? Because it's impossible, because of a bug that came about because the PHP developers didn't understand object oriented programming when they tried to imitate Java's class system.
Python has no trouble implementing ActiveRecord-like ORMs, and even has much more advanced SQL database toolkits than ActiveRecord. What does PHP have that compares with Python's SQLAlchemy?
-Don
Take a look and feel free: http://www.PieMenu.com
For beginners register_globals can create nasty suprises, but for those who know that it is on and write the code accordingly, I don't see what is the problem with register_globals being enabled.
One of the biggest problems currently with PHP is the lack of good database module with support for multiple different database engines with things like prepared statements.
- Raynet --> .
Most PHP programmers ARE beginners, so it creates many many unnecessary nasty surprizes. And for experts, it does not give you anything that you can't already do another way. It adds no real value to the language for experts (of which there are few), and totally screws beginners (of which there are many). Now please explain why you're apologizing for PHP and making excuses for why register_globals is still part of the language after all these years everyone knew it was wrong? I ask again: why did they make such a horrible mistake in the first place?
That's ironic, because people often repeat the myth that PHP makes it easy to interface with the database. Easy but deadly. The reality that PHP has horrible database handling is what's causing PHP programmers to defect to Ruby on Rails (which has ActiveRecord) in droves. Zend tried to imitate ActiveRecord but that resulted in the ZActiveRecord Boondoggle. Python has some excellent database interfaces and object-relation mappers, like SQLObject and SQLAlchemy, which beat the pants of anything PHP has to offer.
-Don
Take a look and feel free: http://www.PieMenu.com
The grandparent is correct. The PHP developers are shit, and they wrote a shitty implementation of a shitty language with shitty libraries. And it will never get any better, because only shitty developers use or care about PHP.
I'm not familiar with the internals of Ruby, but Perl is surprisingly well written.
I recently installed modsecurity http://www.modsecurity.org/ for apache along with the
rules from http://www.gotroot.com/ and it's done a good job of blocking attacks
on my server including a lot of the php mail() injection attempts.
ozgur uksal
How do you really feel, Don? Don't hold back for our sake.
Seriously, while I agree in spirit, what PHP has going for it isn't "irresponsible PHP fan-boys" as much as it is a good ol' network effect. Every host has it and deploying a PHP application is often just a matter of uploading the file and going. (In the immortal words of Jeff Goldblum, "There's no step three!") Contrast that with Ruby on Rails; you have to find a host that will host a Rails app, and as I'm learning, some of the ones that say they do have a lot of caveats on their basic plans (I'm looking at you, TextDrive, with shared hosting process size limits that make running Rails... problematic, shall we say). Assuming you manage to get things set up with Capistrano you're golden. Unless you gotta move providers for some reason. If you do, you're not just dumping your database file and zippin' up the application directory like you would with -- yes -- PHP. While I haven't used Django or Python-based apps, many of the concerns are, from what I've seen, similar.
Yes, yes, I know: none of these things make PHP any better as a language, all of them could be addressed through proper education, and so on. All true. But I'm gonna go out on a limb and guess that you're hostin' your own web site on Drupal rather than Django (or whatever) for reasons other than being convinced by droves of sloppy, uneducated programmers. And those reasons are the ones that need to be addressed. Until deploying Rails, Django, Seaside, or whatever else is as easy as deploying PHP, then PHP wins. The most repeatable (if oft depressing) lesson of modern technology is, arguably, convenience trumps all other considerations.
If they are problems which are not being fixed then why not fork the PHP code base and apply your security fixes, no ones stopping them and this is the point of open source software.
If something isn't being done then you have to do it yourself.
If you don't see what the problem is, then you're not smart enough to code accordingly.
One of the biggest problems currently with PHP is the lack of good database module with support for multiple different database engines with things like prepared statements.
Look at Pear::DB or PDO (in PHP 5).
I am not apologizing, perhaps I am just stupid or something, but I really don't see the problem with register_globals. Perhaps you could point me to some well written article on why it is so fundamentally bad design.
And I said, database handling is what in my opinion sucks the most in PHP. Some anonymous commented about Pear:DB and PDO, and PDO looks at a glance to be quite an improvement, so perhaps PHP6 gets it right...
- Raynet --> .
I'm all for capitalism: vote with your feet! Those hosting providers who only host old poorly configured versions of PHP, and refuse to host decent versions of Ruby and Python, totally deserve to go out of business. So stop sending them your money! It's not like it's hard to find a better one. And I'm sick and tired of all the spam and break-in attempts I get because there are so many security holes in PHP running on those cheap hosting providers' hijacked servers.
Somebody paid me to do some Drupal programming, so I decided to learn it by installing it on my development server, using it for my own blog, reading the source code, and writing my own module (which exports an OPML site map based on the Drupal taxonomy, which dovetailed with my Laszlo OPML Drupal Taxonomy Site Map Browser). As PHP code goes, Drupal is pretty clean and well designed, because it refuses to use PHP's fucked up object system, and rolls its own instead. If course it's clumsy since its own object system is not directly supported by the language (and PHP isn't extensible like Lisp, whose macro system and CLOS lets you elegently roll your own object systems that are seamlessly integrated into the language). But Drupal's html generation facilities and user interface suck.
Sure I would love to try Django, but nobody's offered to pay me to learn it, and I have other stuff to do. I have spend a lot of time doing Zope and Plone development, and was trying to use it as a blog, but I was not satisfied with it (it's very frustrating and much too complex), so I moved over to Drupal because somebody wanted me to do some Drupal work. Ideally I'd write my own blog in TurboGears, which is currently my favorite Python web framework, but I don't have time for that either (and I'm not satisfied with any of the "Write a blog in 2 minutes" screencast example blogs, as cute and furry as they are). I'd rather spend my time developing software instead of writing about how I would be developing software if I weren't writing about it (like I'm doing right now, ironically).
You're certainly right about convenience trumping all other considerations. But building an elementary school out of radioactive wastes, asbestos insulation and lead flashing, exterminating bugs with DDT, hiring drunks to drive the school busses, and contracting McDonalds to run the cafeteria, may be convenient and expedient, but it's unwise and irresponsible.
Until people who understand the dangers start loudly and publicly warning other people about them, there is very little chance of changing those horrible yet convenient practices. That's what Stefan Esser and I and other people are doing, because it's important to discourage people who don't know better from choosing to use PHP when there are much better alternatives, and embarass the PHP developers who should know better into fixing their fucking long standing security problems and bugs (because nothing else has worked).
-Don
Take a look and feel free: http://www.PieMenu.com
If there isn't a problem with register_globals, then why are they finally taking it out of the language? Of course the real questions are: why did it take so long to remove from the language, and why was it ever there in the first place? That is even more evidence of extremely bad judgement on the part of the PHP designers, that they mad such a bad mistake in the first place, and took so long to admit they made a mistake and correct it. They still try to blame it on "bad developers", but that's the only kind of developers they have left any more, because anyone with any sense or choice in the matter has moved on to better languages like Python and Ruby.
Doing a google search for register_globals site:www.us-cert.gov shows 112 references to security vulnerabilities having to do with register_globals. Is that enough evidence that register_globals is a bad idea?
The register_globals flag should not even be an option, backwards compatibility be damned. When you have security holes like "Unsafe termination of parse_str() may result in the register_globals directive turned back on, you're screwed even when you turn it off, because PHP turns it back on internally, then wets its pants before turning it back off, so it leaves it on for the rest of the lifetime of the web server.
That terrible bug was found AND FIXED by Stefan Esser (the person who this thread is about, in case you didn't bother to read the article), yet some piss-water-carrying PHP fan-boys are still attacking him as a "traitor".
Here is another article he wrote about PHP security problems having to do with register_globals and a lot of other stupid flaws that should have never existed in the first place: Zend_Hash_Del_Key_Or_Index Vulnerability. If you don't like it when people blame the Zend Corporation for so many of the problems in PHP, then maybe you should ask Zend to stop putting their company name into all those functions that are the root cause of so many security problems.
-Don
Take a look and feel free: http://www.PieMenu.com
Oh man Smarty source code is just a hoot. Look at this stuff:
The rats-nest of regular expressions in Smarty_Compiler.class.php, and how they're used along with even more regular expressions scattered throughout the code.
That's the typical kind of seat-of-the-pants half-assed parsing that Smarty is rife with. In this case, it gleefully accepts "))((" as balanced parenthesis, and doesn't ignore parenthesis in strings! Why even bother checking, if the check's obviously not correct?
Smarty just heuristically interprets text in a bizarre, poorly documented, non-standard, arbitrary accidental syntax, by slinging around inscrutable regular expressions, parsing text bit-by-bit, making exceptions and special cases, guessing and fudging and cutting corners all along the way. It's so haphazard and mixed up, it's impossible to write a decent emacs text editing mode for it, let alone edit, validate and process your Smarty templates with standard off-the-shelf XML tools. That's why Smarty is such a vile, poorly designed templating language.
-Don
Take a look and feel free: http://www.PieMenu.com
The other Month of Bugs are a little ***useful***! Exposing that things are less secure than they seem, and so forth. But everyone knows that PHP has more bugs that the worst hotel's mattress! If someone sees a point, tell me!