Month of PHP Bugs Has Begun

An anonymous reader writes "The previously announced Month of PHP Bugs started three days ago, and already lists 8 security vulnerabilities in PHP and PHP related software. From the site: 'This initiative is an effort to improve the security of PHP. However we will not concentrate on problems in the PHP language that might result in insecure PHP applications, but on security vulnerabilities in the PHP core. During March 2007 old and new security vulnerabilities in the Zend Engine, the PHP core and the PHP extensions will be disclosed on a day by day basis. We will also point out necessary changes in the current vulnerability management process used by the PHP Security Response Team.'"

Comments

Defective by Design?

[Ckwop]

We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct.

Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design? If so, why so and how would Slashdot seek to fix it?

Simon

Re:Defective by Design?

[SCHecklerX]

Use perl instead :)

Not entirely joking. I use embedded perl for my own dynamic sites, and keep track of the lists, and can't recall any serious known flaws with that implementation.

The vulnerabilities that keep popping up (and the fact that I already know and am comfortable with perl, have CPAN, can develop quickly especially now that I have my own base modules set up, etc) are one reason that I never really looked into PHP.

Re:Defective by Design?

[julesh]

Is PHP defective by design?

It was. A lot of work has been done in the last couple of major versions to fix this, but still a lot of installations are crippled in the name of backward compatibility.

Most of what we're seeing here though is just run-of-the-mill sloppy coding. Create a lot of references to a variable and overflow its (16-bit) reference count? Please. That should never have happened.

Fortunately, it seems most of the bugs released so far don't affect the majority of installations. We have a number of 'executing arbitrary PHP code can let somebody own your web server' -- well, most of us don't let random people run arbitrary PHP code anyway. We have some 'deserialising arbitrary data can let somebody own your web server' issues too, but then there has been a long-standing warning that PHP's deserialise function isn't secure anyway, so that shouldn't affect anyone who's been paying attention. We have some issues with the Zend Platform, but I'm not sure how many people have that installed. So far, the only issue to affect me, is the phpinfo XSS vulnerability -- and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.

Re:Defective by Design?

[Anonymous Coward]

Uhmm, you are aware that all the phpBB forums out there use unserialize() on cookie data?

And phpBB is just one of many popular applications that do it...

Re:Defective by Design?

[julesh]

Uhmm, you are aware that all the phpBB forums out there use unserialize() on cookie data?

No, I wasn't. One more reason not to use phpBB, I guess.

Re:Defective by Design?

[Anonymous Coward]

Is PHP defective by design?

It was.

It still is. Security is not a property of software, or even software design. It's a property of the development process, and it's something that the core PHP developers have failed to get time and time again.

It's true, they've fixed some glaring problems over the past couple of major versions. But they've done it because they've been nagged and shamed into doing so. They still don't have proper processes in place, they still don't get it, and I'm pretty sure they are going to use the fact that Stefan is the one behind this month of bugs as an excuse to call foul. Sure, they'll fix the bugs because now they have no other option (bear in mind some of these bugs have been known for a long time), but they'll totally avoid thinking about what caused these problems in the first place, and ultimately it will change nothing.

Re:Defective by Design?

[julesh]

I think PHP has got beyond the stupid-design-flaws-causing-security-issues stage. Now, as you correctly point out, the major issue is endemic insecure programming practices and a lack of attention to bug reports.

How I wish we could just junk the language and start again with something else; unfortunately, market pressures being what they are, I'm afraid we're stuck with it, at least for the time being.

Re:Defective by Design?

[Anonymous Coward]

And phpBB is just one of many poorly written applications that do it...

Welcome to a security problem everyone else had fixed 5 years ago, the only thing that should be stored in a cookie is a session id! WhatWG DOM storage is being created because of idiots (like those ASP.NET clowns) passing serialized data back and forth in cookies or hidden form fields.

Re:Defective by Design?

[Phantombrain]

If you read the website, you would have seen that the unserialize bug was fixed in PHP 4.4.5

Re:Defective by Design?

[Anonymous Coward]

the major issue is [...] and a lack of attention to bug reports.

I don't think that's fair. I've anonymously reported a handful of bugs over the past couple of years and most were fixed within 24 hours. Here's one I recall from last year (yes I admit that particular one is not really a core bug). I'll criticize PHP until I'm blue in the face but my experience with bug fixing has been an overall positive experience.

Re:Defective by Design?

[mbyte]

That would imply that PHP was designed .. rather than something happened by accident ;)

Re:Defective by Design?

[hutchike]

...or you could target PHP at the Java JVM and benefit from the security built into Java?

Re:Defective by Design?

[eneville]

Use perl instead :)

Not entirely joking. I use embedded perl for my own dynamic sites, and keep track of the lists, and can't recall any serious known flaws with that implementation.

The vulnerabilities that keep popping up (and the fact that I already know and am comfortable with perl, have CPAN, can develop quickly especially now that I have my own base modules set up, etc) are one reason that I never really looked into PHP.

the problem with perl is that i tend to use it for system administration purposes rather than making websites. php is just better for making sites as it is generally setup OOTB, almost a de facto for apache. the programmer should be aware of general problems, the magic_quotes implementation was designed to help programmers, but i think it introduced more code paths.

Re:Defective by Design?

[aaronwormus]

> I had to delete my phpinfo.php file that I kept in the root of each domain I host.

if you left an open phpinfo() on your server (giving potential attackers access to filepaths, module version numbers, configuration options, apache server configuration options), you have a lot more to worry about than a little XSS.

unfortunatly, you're not alone.

Re:Defective by Design?

[Dan Ost]

Actually, lots of people have abandoned PHP for Python and Ruby.

It may never completely go away, but there are alternatives to using it.

Re:Defective by Design?

[Anonymous Coward]

So far, the only issue to affect me, is the phpinfo XSS vulnerability

You have something to prevent people from requesting /whatever.php?a[][](etc)=1&a=0 to trigger that recursive overflow crash?

Re:Defective by Design?

[nuzak]

Done. http://www.caucho.com/resin-3.1/doc/quercus.xtp

Re:Defective by Design?

[Anonymous Coward]

Last time this story cropped up on Slashdot, somebody pointed out a bug report where an unprivileged user could segfault the server due to a flaw in the MySQL extension shipped with PHP - the bug was closed as "user error". I've personally reported a (non-security-related) bug that has been treated in a similar way. Another bug I've reported was met with "well I'll think about fixing it if I get around to it". I've seen plenty of things of this nature.

Re:Defective by Design?

[cheater512]

PHP its self is very good. Its the sloppy coders who give it the bad name.

I've seen atrocious code where you can tell that just because the coder knows how to do a for loop in BASIC it means it can become the next Bill Gates.

Re:Defective by Design?

[julesh]

If you read the website, you would have seen that the unserialize bug was fixed in PHP 4.4.5

Doesn't mean calling unserialize on untrusted data is a good idea. Unserialized data may be of any class, and code may be automatically executed in it during the unserialization process. This means an attacker may be able to execute code you were not expecting to be executed, potentially leading to any of a number of exploit scenarios. Unserializing untrusted data in PHP (and many other dynamic languages) is a bad idea.

Re:Defective by Design?

[cheater512]

Hey I use other people's phpinfo pages for debugging HTTP headers. :)

Its bloody helpful.

Re:Defective by Design?

[julesh]

Actually, lots of people have abandoned PHP for Python and Ruby.

It may never completely go away, but there are alternatives to using it.

Not really. Most of us in the off-the-shelf web package software development industry are constrained to develop in whatever's available on the servers our clients are likely to choose. An informal survey suggests that of 5 popular hosting providers in my local area, only 1 offers anything other than PHP or Perl/CGI in their basic level package. With this kind of support, we'd be crazy to develop our software in any other environment. Sure, if you're building a site for yourself to use with a hosting provider you can choose, and your budget isn't so tight you have to go with the cheapest available, you get a choice of environments. Most people aren't in that situation -- most people have to use packaged software, and the packaged software vendors are in the same situation I'm in that it is market suicide to use anything other than PHP (or, for a significant minority, ASP.NET).

Re:Defective by Design?

[arodland]

Nope. Definitely defective by lack of design.

Re:Defective by Design?

[Anonymous Coward]

I happen to think that Python and Ruby (fine scripting languages that they are) make poor replacements for PHP. Haxe or Pike are better but not as widely available.

From a hosting perspective, I'd like everyone to target parrot and we can have done with it.

Re:Defective by Design?

[julesh]

You have something to prevent people from requesting /whatever.php?a[][](etc)=1&a=0 to trigger that recursive overflow crash?

Yes; I have set up my server to reject requests with GET/POST variables that have unrecognised names. The '[]' would trigger that rejection.

Re:Defective by Design?

[jadavis]

I think PHP has got beyond the stupid-design-flaws-causing-security-issues stage.

A major problem for PHP is still it's configureware mentality. No other programming language has a configure file. PHP started with it because it's also a web framework; which is somewhat understandable. However, they then proceeded to abuse the configuration file for all sorts of semantic behaviors, and the end result is that it's very HARD to program securely and portably at the same time. Make a configuration change, and that could introduce a subtle security flaw.

magic quotes is probably the worst idea that PHP ever had.

Re:Defective by Design?

[Anonymous Coward]

>and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.

Please. That should never have happened.

I've never taken a university-level CompSci class in my life, and even I know you don't make filenames the same as revealing functions. Much less store them at root.

Do you have sudo.sh as well? Let's check...

Re:Defective by Design?

[Anonymous Coward]

Apache child segfaults on malformed POST data, I'm still thinking about that one. I think a mod_rewrite rule can work around any issues or perhaps PHP auto-globals JIT can be back-ported?

Re:Defective by Design?

[cerberusss]

How I wish we could just junk the language [PHP]

At least it's better than Perl.


*ducks*

Re:Defective by Design?

[cortana]

That implies that PHP was designed in the first place.

Re:Defective by Design?

[tobiasly]

and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.

Heh... guess I'm not the only idiot that does that. :) Even though I'm running 5.x and that bug doesn't affect me, I've known it was a stupid idea for a long time but laziness prevailed. You and the PHP bugs project have just given me the motivation to fix that!

Re:Defective by Design?

[jZnat]

Just wait for Debian Etch; that should help update a lot of hosts into using modern languages (including modern versions of PHP).

Re:Defective by Design?

[kestasjk]

It was actually the cause of a security hole a while back. They unserialize your MD5 hash (which isn't salted by the way), and check whether it == the hash retrieved from the database.

But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.

Re:Defective by Design?

[LittleDobbs]

I'm not trying to say that's not an bug but... The exploit requires the PHP code to recursively traverse the array. The request it self does not cause the crash. This can actually be prevent with good PHP code. So it's possible to not be effected by that bug. Granted even with good PHP code the request takes a long time to handle.

Re:Defective by Design?

[WoodstockJeff]

But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.

Strange, I'm looking at the code for phpBB2 v2.0.22 in my editor right now, and there is no occurrence of code like you mention. That sort of problem was cleared up well over a year ago, when it was first revealed to be a problem. In every case where unserialize() is used, its output is assigned to an array, and then pieces of that array are compared to the variables in other arrays. If someone attempts to "stuff" a value in to replace the MD5 retrieved from the database, it would not be used. To use your example, it would be stuffed into $sessiondata['inputHash'], not into $inputHash.

This is not to say that a lot of hacks (aka "MODs") do not play loose with unserialize()... but some of them make far worse errors. And, of course, there are a great many people running versions of phpBB (and other apps) that are far older, and still have the bug.

One of my pet peeves with PHP is that if I decide to disable URLs for include and require, it eliminates any possibility of making outbound connections. I have several applications where programs sanitize data from clients, then format and submit it to a remote XML server via HTTPS. Those servers would cease to function if I blocked URL open for includes, which is one of the most common ways of taking over a server with certain PHP applications installed. Of course, the fact that we control all the software on these servers (no third-party sites) means there little chance of that particular vector, but it would be nice if they had separate controls for opening a file resource and a include source... It will be interesting to see if that makes the list.

Re:Defective by Design?

[caluml]

mod_security and Hardened PHP can help with preventing future attacks that people don't yet know about.
Also, using something like GRSec, or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.

Re:Defective by Design?

[Anonymous Coward]

Read the comment above yours for a clue. Apache does a 414 "URL too long" if you do a GET, try a POST and you'll see that you don't have to traverse the array at all; PHP segfaults on allocation into the global $_POST array.

Both auto global JIT and hard limits would be the correct fix. IMHO anybody needing a multidimensional array over 128 levels deep can damn well make an ini change.

Re:Defective by Design?

[mangu]

Actually, lots of people have abandoned PHP for Python and Ruby.

I don't know about Ruby, but I do a lot of programming in Python. Let's see:

#!/usr/bin/python
a = 1
b = 1.
if a == b: print "they are the same"
if (a / 3) != (b / 3): print "they are not the same"

Oh, come on, where's that '===' operator when one needs it???!

Re:Defective by Design?

[LittleDobbs]

Maybe JIT is why I can duplicate this on my PHP I don't know why wouldn't have this option on. Anyway I didn't get a 414 from the curl in MOB applied to my test.php

Re:Defective by Design?

[LittleDobbs]

Arrg notice my on typo. That should be can't duplicate this.

Re:Defective by Design?

[Anonymous Coward]

People call Vista, "defective by design" because Microsoft specifically went out of its way to put defects into the product. Having the OS provide support for DRM and automatically degrading the picture quality of signed files is a defect that you specifically have to program for. Hence defective by design.

PHP is not defective by design, its defective by lack of design. PHP has largely grown organically rather than focused and security just wasn't one of the priorities of the project until more recently after 5 major versions.

Re:Defective by Design?

[Anonymous Coward]

Check your per script memory limit, default is 8MB and the 20,000 int value in the POC causes a crash with that. Here's a script to crash apache with much bigger array.

<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">
<input type="hidden" name="<?php echo 'a',str_repeat('[]', 9999999); ?>" value="1" />
<input type="submit" value="crash" />
</form>

Then tail the Apache error_log to see the seg fault. Here it is from cli:

<?php
error_reporting(E_ALL);
 
echo "This will crash PHP with default (8MB) memory limit\n";
$crash='$a'.str_repeat('[]', 20000).'=1;';
eval($crash);

And running it:

sandbox@localhost ~ $ php -e crash.php
This will crash PHP with default (8MB) memory limit
 
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 7864320 bytes) in /home/sandbox/crash.php(6) : eval()'d code on line 1

Re:Defective by Design?

[Anonymous Coward]

Hmmm, ignore me. I can't reproduce the actual bug - think I must have just been seeing memory errors terminating Apache child process.

Re:Defective by Design?

[Anonymous Coward]

Er, you do a lot of programming in Python, but you don't realise that it's a rounding problem not an identity problem? Divide an integer, and you get an integer result. Divide a float and you get a float result. The two divisions *should* have different results. If you want a float result from an int division, use a cast.

Re:Defective by Design?

[Dan Ost]

from future import division

would fix this for you if it really bothers you.

Re:Defective by Design?

[Wann_2275]

I aggree. The poorly designed application usually will lead to future vulnerability problem. We all knew that any software or application that are well written (in terms of coding), are seldom lead to future security threat. The manufacturer really needs to do something before the users turn to other more 'trusted' scripting langguage. And before it causes to lot more damage.

Month of bugs, will it change things for better?

[chabotc]

To be honest i'm glad that this month of bugs is happening, after all the previous news items about how the core php / zend team is refusing to colaberate with some ppl who are deeply concerned about php's security (and by this we do mean mistakes/faults in the php engine, not in bad php programming).

On the other hand, i bet a fair few of the released vunerabilities will be applicable for many websites that the company i work for hosts, and i know corperate policy doesn't include frequent updates to their envirioment, there's just to many sites, to many badly supported applications by/for customers, and just to damn many servers to work with easily, i can't imagine were the only such company with such problems... And it really makes me wonder if this will mean that many hundreds of our hosted websites will from now on be easily hackable by scriptkiddies

Should prove to be interesting times, and who knows maybe it will teach our admins to use yum/rpm's for their servers instead of compiling their own apache/php combinations :-)

Just in case..

[loconet]

To clarify, note that these bugs are related to the PHP core, not the language itself which may result in insecure applications. The statement that 8 security vulnerabilities in PHP and PHP related software is not referring to PHP software such as Wordpress. I mean seriously, I think I saw my dog hacking together a blog the other day using PHP. Everyone uses the language and not everyone has the background to know what they should and shouldn't be doing. In addition to its popularity, the language and its "libraries" make it easy for untrained coders to leave gapping holes in the code. Don't get me wrong, I love PHP (to an extend), I make a living out of it but any attempt at fixing "PHP related software" directly (ie: wordpress,phpbb,oscommerce,etc) would take more than a month.

Re:Just in case..

[FooMoeDee]

these bugs are related to the PHP core...I make a living out of it You're the most qualified person currently available to hypothesize on an attack vector and a path to a full-fledged exploit. Will you share any thoughts?

Re:Just in case..

[Toba82]

I cannot agree more. I use PHP extensively and to be honest, none of the PHP 'exploits' have ever effected any of my scripts. In one case where a GET variable contains a base64 encoded serialize()ed structure, I included sha1 and md5 hashes in the URL that have to match for input to be accepted... I did this a year ago, because I had a feeling that unserialize could be unsafe. Evidently, I was right.

In a shared-hosting situation, I can see why these would be a much bigger problem.

Re:Just in case..

[ravenlock]

Exactly how is that secure if you trust the client for both the content and the hash?

Re:Just in case..

[Toba82]

Oh, I forgot to mention it: the content is padded with a key before hashing.

Re:Just in case..

[ravenlock]

And that key is not trusted to the client? In that case, what does that add to just keeping the hash on the server side?'

Not trying to be an ass here -- I just suspect I'm a bit dense today, so a more thorough explanation would be nice. :)

Re:Just in case..

[Toba82]

OK, enough discussion. Here's the code if you care so much. The encoded data can be passed via POST or GET variables safely (unless sha1 weaknesses make the cryptographic security faulty).

http://toba.ath.cx:724/~eastein/ser.html

Re:Month of PHP Bugs Has Begun...

[namityadav]

There are so many "Get me a portal, quick" / "I want to create a CMS that will make me rich" websites based on PHP based solutions that this exercise becomes obviously very important. It's surprising how many of such websites are severly insecure.

Er...

[John Nowak]

Just one month?

Re:Er...

[eneville]

Just one month? lets hope someone fixes mail()

Re:Er...

[jZnat]

Way ahead of you.

Re:Er...

[Bastard of Subhumani]

Never heard of the September that never ended?.

vulnerable

[IT 073571]

Beware of the unexpected behavior of a program... it brings joy to hackers all around the world.

Defective by Design == DRM

[wuputah]

"Defective by Design" usually refers to DRM, since that is what the FSF's campaign against DRM is called.

The simplest fix

[Anonymous Coward]

One of the biggest problems with PHP is the die-hard adherance to backwards compatibility. Functions don't get deprecated, the API doesn't change, it gets overloaded with nearly-the-same but-not-quite methods so that somewhere, somebody doesn't complain about how their website "broke" with the latest release--never mind the fact that by using insecure functions, their sites are already broke.

Re:The simplest fix

[epine]

One of the biggest problems with PHP is the die-hard adherance to backwards compatibility. Functions don't get deprecated, the API doesn't change, it gets overloaded with nearly-the-same but-not-quite methods so that somewhere, somebody doesn't complain about how their website "broke" with the latest release--never mind the fact that by using insecure functions, their sites are already broke.

It goes beyond that. When the new API variants are released, details the actual problem resolved are usually found deep in the discussion and not the primary document itself.

Does the main documentation for unserialize call any attention to the hazards associated with it?

http://ca3.php.net/manual/en/function.unserialize. php

I have no particular grudge against PHP. I used it myself for small projects because the language is relatively easy to relearn on the fly. Perl demands too much head space to use it less than once a month. However, when you decided you really want to get a function right, you tear your hair out trying to get an exhaustive account from the online PHP documentation of the issues you need to concern yourself with.

The PHP project brought the month of bugs onto themselves. The simplest measure they could have taken was to make prominent in their online documentation the risks associated with each function PHP provides. I have no problem with caveat emptor. In fact, I've always shunned the languages that attempt to save me despite myself. The lack of prominent "beware of dog" signs in the online PHP documentation is what drives the security split within the PHP community: allowing one camp to remain lax, while the other camp becomes increasingly strident.

I regard this "month of bugs" as long belated complement to the online PHP documentation for concise information on the risk side of the equation.

die PHP die

[Anonymous Coward]

I expect many of us have some heavy patching to do this month. PHP devs refused to take the opportunity to break BC and fix the language/runtime with PHP5.

When will OpenJDK be usable serverside? I think I'd prefer to spend the month converting a bunch of PHP apps to Java instead of applying patches.

Re:die PHP die

[eneville]

I expect many of us have some heavy patching to do this month. PHP devs refused to take the opportunity to break BC and fix the language/runtime with PHP5.

When will OpenJDK be usable serverside? I think I'd prefer to spend the month converting a bunch of PHP apps to Java instead of applying patches. not everything will benefit from the conversion. some objects take much time to construct in java, and generally things will perform worse. there are some things that can benefit from being a bean though. loading a huge array, of perhaps loginids statically would perhaps save some database work. it's hard to say. but for most people i would estimage 6-12 months for the conversions.

Re:die PHP die

[chez69]

java memory allocation is as fast as if not faster then malloc.

enjoy

Re:die PHP die

[eneville]

java memory allocation is as fast as if not faster then malloc.

enjoy
i cant see how that statement can be true. the JRE might be able to allocate at that speed, since it is machine level, but the application cannot, since it has to be interpreted and then the allocation can occur.

thats not my point though. the point is that String s = "abc"; is not as fast as strcpy( s, "abc" ); for obvious reasons.

this could fork off onto a thread all of it's own, but somethings can occur in java faster than in php, as php does not have beans. beans provide a means of loading something common just once, and then it's available for future instances. this could avoid a lot of db calls that php scripts might require.

Re:die PHP die

[chez69]

>>i cant see how that statement can be true. the JRE might be able to allocate at that speed, since it is machine level, but the application cannot, since it has to be interpreted and then the allocation can occur.

it's because of how java manages the heap. it asks for a chunk of memory from the OS on startup, when you want an object, it just marks the memory as used and returns the pointer.

read the article and see some of the clever things the JVMs do now with memory management, it's really cool.

>>thats not my point though. the point is that String s = "abc"; is not as fast as strcpy( s, "abc" ); for obvious reasons.

if it doesn't have to allocate the memory first, then it's faster. modern JVMs make String s = "abc" static anyway since strings are immutable (I believe java 5 & 6 both do this)

I'm not bashing PHP, you just need to be aware that java has changed alot since the shitty applets of 1.0.2.

Re:die PHP die

[eneville]

I'm not bashing PHP, you just need to be aware that java has changed alot since the shitty applets of 1.0.2. i was prising java earlier on... i never said that it's better/worse than php, only that there are some common sense things that can be done to improve performance via beans.

Also version 4 predominates

[Mateo_LeFou]

I've used PHP5 exclusively for over a year, for well-publicized reasons.

Re:Also version 4 predominates

[Anonymous Coward]

PHP 5 broke my wikis :(

Re:Also version 4 predominates

[LittleDobbs]

Your Wikis were already broken PHP 4 just lets them work. Or I should say the Wiki's are poorly coded which is why the upgrade didn't take. Kind of like saying IE 7 breaks a web page when in fact the broken HTML is the problem.

Re:Also version 4 predominates

[tolan-b]

That's not entirely true. There are breaking changes in PHP5 for non-deprecated behaviour.

Parent isn't flamebait

[blincoln]

It's a legitimate question.

I just started using PHP a few months ago for a few utilities on one of my websites. There are a ton of things about the language that seem half-assed. In particular I'm thinking of:

- The entire mysql library, which I have to use right now because mysqli apparently isn't enabled by default in PHP 4 and my current host won't turn it on or upgrade to PHP 5. Why is the default behaviour to force the use of SQL injection-vulnerable code?
- There is no equivalent of a "contains" method for the string class, with strpos() being the recommended alternative. strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for.
- Dynamically-typed variables. Worst code/script idea evar. Yes, I realize PHP is not alone in this.

Basically to me it looks like the *ix version of VBScript. In its favour, it does use curly braces instead of MS' stupid "If something Then doSomeOtherThing End If" syntax.

Re:Parent isn't flamebait

[Aladrin]

So your webhost won't upgrade, and that's PHP's fault? PHP5 has been out a LONG time. Don't bother complaining about bugs in PHP4 simply because your website can't be bothered to upgrade. Find a decent webhost instead.

strpos() return FALSE when it can't find the 'needle'. http://us2.php.net/strpos Use a proper test (===) and you'll have all you need in a single statement.

Some people really LIKE dynamically-typed variables. It's not a bug or a problem. It's a design choice.

Your flamebait at the end (vbscript) does nothing to enhance your argument. Leave it off next time.

Re:Parent isn't flamebait

[Anonymous Coward]

> There is no equivalent of a "contains" method for the string class, with strpos() being the recommended alternative. strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for.

strpos? *and* a separate check? strstr not good enough?
Returns false if string A does not contain string B, otherwise it is contained. What about preg_match?

Re:Parent isn't flamebait

[Anonymous Coward]

strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for.

WTF are you smoking()? From the manual:

If needle is not found, strpos() will return boolean FALSE.

Like this:

$result = strpos($haystack, $needle);
if ($result === false) die("$needle was not found\n");

Re:Parent isn't flamebait

[TheNinjaroach]

There is no equivalent of a "contains" method for the string class, with strpos() being the recommended alternative. strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for. Use === with your comparison. Yes, dynamically typed variables can be a pain but only if you don't understand how to use them. Look at the following example:

$inputstring = "This is my PHP script";
if(strpos($inputstring,"This") === false) echo "Not found in inputstring"; //This does NOT evaluate to true because 0 is NOT === false
if(strpos($inputstring,"This") == false) echo "Not found in inputstring"; //This WILL evaluate to true and echo happens because 0 == false

So your criticism of dynamically-typed variables is valid and is what confuses you when it comes to using strpos().

Re:Parent isn't flamebait

[cheater512]

Just because you havent learnt about how the type system works doesnt mean its crappy.

Re:Parent isn't flamebait

[Anonymous Coward]

The mere existence of something like "===" tells more than enough about the "defective by design" state of PHP.

Re:Parent isn't flamebait

[Anonymous Coward]

Dynamically-typed variables are for sloppy programmers who can't be bothered with details. Hey, typical PHP writer!

Re:Month of bugs, will it change things for better

[Anonymous Coward]

after all the previous news items about how the core php / zend team is refusing to colaberate with some ppl who are deeply concerned

DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL! DO NOT SAY PPL!

Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's likeLameness filter encountered. Post aborted!
Lameness filter encountered.
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.
Reason: Don't use so many caps. It's like
Lameness filter encountered.
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's likeLameness filter en
Lameness filter encountered.
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.countered. Post aborted!
Reason: Don't
Lameness filter encountered.
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. use so many caps. It's li

Typical

[dysfunct]

Stefan Esser has found some interesting yet not too surprising vulnerabilities in PHP. All those scenarios described in the various vulnerability reports are very typical for the development process of PHP and many similar ones have already been found and reported. The same goes for the fact that many of those are simply WONTFIX. A perfect example for the general attitude regarding a remote code execution vulnerability cited here:

Because the PHP developers do not want to fix this anymore because it creates problems for companies providing closed source PHP extensions the only potential workaround is to manually change the size of the reference counter in your own PHP. However if you do so you have to recompile all your PHP extensions and cannot use closed source PHP extensions anymore.

I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more, which leads to improper and I even dare to say incompetent handling of reports and fixes (many of which simply get applied somewhere down the road without proper announcement or mentioning anywhere in the CHANGELOG) as well as seemingly ignorance regarding more complex vulns that are just as relevant as the glaringly obvious ones but simply not as mass-exploitable by script kiddies.

And *this* is the big problem that PHP is facing today regarding enterprise support. Maybe Jon Doe's blog installation is not as mass-exploitable by a script kiddie any more as it used to be some years ago, yet Big Company's CMS is still vulnerable to complex attacks by an experienced attacker who might use published attacks that security experts know about, yet end users do not.

Re:Typical

[Unknown Relic]

First of all, the issue HAS been fixed in PHP5 and above. Secondly, this is NOT a remote code execution vulnerability. The only way it can be exploited is by already having the ability to make the server run arbitrary scripts.

Yes, in a shared host environment it potentially allows users to bypass safe mode and open basedir restrictions, however information on how to properly secure PHP for a shared environment has been around for a LONG Time. Not one person on the development team you go so far as to call incompetent would state that safe mode (which has been depreciated) and open basedir are sufficient for that purpose. On a properly configured server this exploit won't let a user do anything but access their own files. This fact coupled with the backwords compatibility break is why it's marked WONTFIX, not because of incompetence or misunderstanding.

Re:Typical

[Anonymous Coward]

I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more

I'm beginning to agree. In two cases, the problem is that the developers refuse to create "arbitrary" limits, and therefore the system succumbs to equally arbitrary limits. For instance, there's a solution here that would make everyone happy: fail to create a reference if it would overflow the reference counter, rather than try anyway and segfault. Yet for some reason the developers don't want to do that... despite the fact that it would simply be enforcing the limit that's already there. Increasing the number of references one can store before crashing the system doesn't fix anything.

Same with the limit on the nested array depth... yet there IS a limit, and because that limit is not enforced, the system can be crashed.

Re:Typical

[dysfunct]

First of all, the issue HAS been fixed in PHP5 and above.

Was there ever a proper back-port to PHP4 or proper announcement of this bug? I'm not exactly an expert on PHP internals but I imagine there might be possibilities to remedy this situation if desired.

Secondly, this is NOT a remote code execution vulnerability.

Yep, you kinda got me there. This might be very, very hard to exploit by using other attack vectors like improper input handling or decoding by PHP itself. Although one mustn't forget that this can be an interesting attack vector for an app-based vulnerability (ie remote file inclusion) if PHP is secured semi-properly since using it you *can* execute shell code, even if exec() etc. is normally disabled. I also think that there *might* be ways to trigger the exploitable behavior remotely in *some* PHP scripts.

This fact coupled with the backwords compatibility break is why it's marked WONTFIX, not because of incompetence or misunderstanding.

I think you misread this. I do not call somebody incompetent easily and unnecessarily. The context was "and I even dare to say incompetent handling of reports and fixes". This in my opinion holds true, as the PHP developers appear to have limited understanding of formal and proper incident handling and therefore limited competency on that subject matter.

Re:Typical

[Anonymous Coward]

HAS been fixed in PHP5 and above.

Does PHP5 check to ensure that you haven't overflowed the reference counter? If not (and the bug report says "In PHP 5 this field is meanwhile 32 bit wide, because 16 bit can overflow too easily and PHP does not have an internal protection against overflows of the reference counter." which leads me to believe that it's still not fixed) then it's only "fixed in PHP5" until someone installs it on a 64-bit system with more than 64GB or so of addressable memory space available, in which case creating 2^32+1 references will still allow you to take over whichever user the webserver is running as.

Fixing this would mean including a check to prevent overflowing the counter no matter how many bits there were in it.

Re:Typical

[CTachyon]

I believe serialize() preserves references -- it certainly does in PHP5 -- and (as mentioned elsewhere in the discussion) several PHP applications unserialize() remote data (notably phpBB).

Now, since the bug is apparently PHP4 only (gigabytes worth of references notwithstanding), the Big Question is whether or not the PHP4 unserialize() restores references.

Re:Typical

[Bloke down the pub]

64 GB? That should be enough for anybody!

Don't beleive it

[attackiko]

Yes, but how many sites get hacked because of PHP and not because of faulty applications?

Not many.

Re:Don't beleive it

[Anonymous Coward]

Now you say that a vulnerability in PHP does not count because there are also vulnerabilities in PHP applications?

It is no wonder that people choose applications to break into servers, because those vulnerabilities can be exploited by every skript kiddie.

To say that PHP vulnerabilities are irrelevant because Skript Kiddies don't use them is plain stupid.

Re:Don't beleive it

[SimHacker]

And how many PHP applications are NOT FAULTY?

Not many!

-Don

How about

[Anonymous Coward]

A month of pointing out the ways PHP sucks ass? I predict roughly 97 million entries by the end of the first week.

Oh Nose!

[FedeLebron]

"A deep recursion of PHP userland code will exhaust all available stack which leads to a sometimes remotely triggerable crash."

I've found a very similar bug in GLIBC!

int main(){
main();
}

This code will cause a segment violation!

Shock! Gasp! Horror!

Re:Oh Nose!

[daverabbitz]

That does sound like a bug in Glibc, it should generate a stack fault.

Re:Oh Nose!

[Anonymous Coward]

And now you hero trigger this bug remotely...

And when you managed that you can compare it to the PHP bug...

And btw... have you looked at python etc... They handle this kind of bug correctly by terminating the script instead of crashing.

Re:Oh Nose!

[julesh]

You do realise the difference between PHP and GLIBC, don't you? PHP is designed to have a "safe mode", which (according to the documentation) is supposed to allow a system administrator to run arbitrary code in the knowledge that it can't do certain things -- one of these things should be crashing the web server.

Re:Oh Nose!

[iluvcapra]

I've observed that a lot of complaints about modern PHP derive from the fact that it's a dynamic interpreted language, but that in many ways it behaves like a compiled, angry, shoot-yourself-in-the-foot language, like C.

PHP will segfault, just like C, if you recurse too far on the stack, but almost every other scripting language has a mechanism for catching a stack overflow as an exception and then letting the programmer handle it. PHP in this case just crashes; even C allows you to register a function to act if your program has a segmentation violation.

The long-complained-about static binding of class methods to their superclass, and not to child classes is in a similar vein. PHP does what C++ does: static methods execute in the scope of the class they're declared in, and not the class the method is called on. This is a requirement if your language is strict and compiled, like C++, but it's completely superfluous if you're running a dynamic language like PHP. It also makes a lot of tricks used by Ruby and Python developers to make slick frameworks basically impossible.

Re:Oh Nose!

[Anonymous Coward]

As it's invalid in C for main to be called, that function should not compile.

Re:Oh Nose!

[suv4x4]

"A deep recursion of PHP userland code will exhaust all available stack which leads to a sometimes remotely triggerable crash."

I've found a very similar bug in GLIBC!

        int main(){
        main();
        }

This code will cause a segment violation!

Shock! Gasp! Horror!

Now you know why web pages aren't generally coded in C. There's a reason people use higher level languages for such tasks, and one of them is that you can NOT crash the server via deep recursion, or have memory leaks when you have a garbage collector.

In defence of PHP

[Anonymous Coward]

I love PHP. It works, it's fast, it get results, it's everywhere, it has a straightforward syntax, it has a huge number of extensions enabling you to talk to just about anything, the online documentation is clear and present, it's free. You can write systems as simple or as complex as you like, you can write wholly procedurally or you can create classes and objects. That's why it's popular. No compiling, no fannying around with JVMs.

You use it, it works. You want to move your site/system to another platform? Just move it. Of course there are problems with things like verb-object, object-verb function naming, the object model is lacking, there are a plethora of similar functions, it can be a trial and error game to escape/unescape strings etc. But for the most part, for what most people want to do, these shortcomings are hardly insurmountable. Most people aren't using PHP to send rockets to Saturn or build massive projects where namespace size becomes an issue. Most people who use PHP have the intelligence to use it intelligently.

I've written some great, popular, scalable, applications in PHP4 and it was (and is) a pleasure. I cannot see why I should learn RoR, or Perl, when I have what works. Maybe somebody could explain why I should?

Re:In defence of PHP

[Anonymous Coward]

If PHP is so horrible, what language should be used to quickie, db-driven sites?
Are Python and Rails really set up to do this OOTB? (That is an honest question.)

Re:In defence of PHP

[brezel]

it's fast, it get results, it's everywhere, it has a straightforward syntax,

i did a lot of testing in my company that showed that creating large html forms from database content in php is 120% slower than in java.

it has a huge number of extensions enabling you to talk to just about anything,

ever tried to access an oracle db from php? not fun.

No compiling, no fannying around with JVMs.

yup, that's why it is slow as hell. also the total lack of type safety and freak operators like === make me want to avoid it. :)

Re:In defence of PHP

[creativeHavoc]

the freak operators like === are a response to the lack of type safety. Not having stict types can be really usefull, and if you code well, irrelevant to the security or performance of your application.

Re:In defence of PHP

[Goaway]

I cannot see why I should learn RoR, or Perl, when I have what works.

Because it is painfully obvious that you have no idea what you are doing, and thanks to PHP's lack of secuirty measures against inexperienced programmers, you are very likely creating tons of highly vulnerable programs.

Other languages tend to have much more secure APIs, letting you get away with not paying as much attention to security. Do yourself a favour and switch to one of them.

Re:In defence of PHP

[damacus]

Accessing Oracle from PHP is child's play. What's the mystery? Besides, the comment was about the extensions and capabilities. PHP is great, though perl is better. I don't know of any other languages that are as flexible in that regard.

Next, 120% slower under [undisclosed] circumstances. Browser rendering, network setup, capabilities of server/client, will impact things.

Additional, and this also relates to your 3rd point, there are are wide variety of PHP accelerators which give PHP quite a speed boost. From Wiki: Most work by caching the compiled bytecode form of PHP scripts to avoid the overhead on every page request of parsing and compiling source code that may never even get executed. For best performance, caching is to shared memory with direct execution from the shared memory and the minimum of memory copying at runtime. A PHP accelerator typically reduces server load and increases the speed of PHP code anywhere from 2-10 times[...]

And yeah, PHP's fast and loose flexibility creates the necessity for things like === however the requirement that one is more aware of how types are handled is easily outweighed by the flexibility it gives the developer and the ease of use.

Re:In defence of PHP

[Anonymous Coward]

Because it is painfully obvious that you have no idea what you are doing

How's that?

Re:In defence of PHP

[LittleDobbs]

Correct me if I'm wrong. By my math with APC and assuming a worse case situation of only 2 times acceleration. This means that PHP should execute in 60% the time of Java

Re:In defence of PHP

[LittleDobbs]

Because it is painfully obvious that you have no idea what you are doing, and thanks to PHP's lack of secuirty measures against inexperienced programmers, you are very likely creating tons of highly vulnerable programs. Or it could be due to an existing code base. I for one do not wish to randomly hire new programmers and convert over 50000 lines of code. Just like I'm sure my bank is going to go ahead and convert all it's COBAL code to Ruby or Python one of these days.

Other languages tend to have much more secure APIs, letting you get away with not paying as much attention to security. Do yourself a favour and switch to one of them. Right because not paying attention to security is what every programmer should do. Language doesn't make a secure program the programmer does.

Re:In defence of PHP

[Anonymous Coward]

I cannot see why I should learn RoR, or Perl, when I have what works. Because it is painfully obvious that you have no idea what you are doing, and thanks to PHP's lack of secuirty measures against inexperienced programmers, you are very likely creating tons of highly vulnerable programs. Other languages tend to have much more secure APIs, letting you get away with not paying as much attention to security. Do yourself a favour and switch to one of them.

That's not an answer. In fact, it's worse than a non answer. A language should let you create an application as insecure as you want it to be. It's not the job of a language to be secure, it's the job of a programmer to write applications that are secure, and the underlying platform/codebase to do what is says on the tin.

To date (touchwood), I've never had an application hacked (to my knowledge), because my application security is session based, I run everything over SSL and I make damn sure I sanitize anything coming into it. The bugs in the code accepted, PHP has done, and continues to do, what it says on the tin.

So give me a real reason to use either Perl or RoR.

Re:In defence of PHP

[Anonymous Coward]

From Wiki

"Wiki" isn't a proper noun, you fucking retard.

Re:In defence of PHP

[RegularFry]

Honestly? No.

The really big thing that PHP gets right - and it's so big that people often don't even see it - is that deployment is really, truly, brain-dead simple. Write some code, drop it in a folder, and it just works. You *really* can't say that about Rails, where you can about, say, CakePHP. This is mainly because Rails isn't internally thread-safe, but that's only a problem because mod_ruby uses a single instance of the interpreter for all requests. That makes mod_ruby a distinctly unpopular deployment target for Rails.

For smaller, non-Rails projects, Ruby can be a good option if simplicity of deployment is paramount, but as far as I know it's rather uncommon.

Re:In defence of PHP

[Goaway]

That's not an answer. In fact, it's worse than a non answer. A language should let you create an application as insecure as you want it to be. It's not the job of a language to be secure, it's the job of a programmer to write applications that are secure, and the underlying platform/codebase to do what is says on the tin.

This is true of C, and no other langauge. It is very much the job of the language to take the burden of security off the programmer and implement as much as possible of it automatically. The only exceptions are low-level code and absolutely speed-critical code. A dynamic language like PHP is neither, and there is no exccuse for endangering programmers and users by doing things like directly importing C APIs for database access. No other dynamic language is so crazy as to do this.

Re:In defence of PHP

[Goaway]

it can be a trial and error game to escape/unescape strings etc

This is absolutely critical to get right in PHP, or you will most likely be toast. And it is not easy.

Re:In defence of PHP

[Goaway]

Right because not paying attention to security is what every programmer should do. Language doesn't make a secure program the programmer does.

So it is totally pointless for Java, or for that matter PHP, to protect against buffer overflows in the language? That is a utterly idiotic argument. Of course you can write insecure code in any language, but that doesn't mean it doesn't matter that it's much easier to accidentially make code insecure in one language than it is in another.

Especially when PHP's biggest market is inexperienced programmers, there is no excuse for the incredibly shoddy design and all the traps it contains that will make your code insecure if you do not know exactly what you are doing, such as the mysql functions which are just imported straight from C. No other language is so crazy as to do that.

Re:In defence of PHP

[Bastard of Subhumani]

it's COBAL

That's another two languages you know nothing about.

Re:In defence of PHP

[mangu]

i did a lot of testing in my company that showed that creating large html forms from database content in php is 120% slower than in java.

And I did a lot of testing in my company that showed that programming large html sites with database content in java is 5000% slower than in PHP.

ever tried to access an oracle db from php? not fun

No, I don't consider it fun either. OTOH, it's very quick and trivially easy, so that makes the lack of fun doing it irrelevant.

Re:In defence of PHP

[brezel]

i did a lot of testing in my company that showed that creating large html forms from database content in php is 120% slower than in java.

And I did a lot of testing in my company that showed that programming large html sites with database content in java is 5000% slower than in PHP.

you lie.

ever tried to access an oracle db from php? not fun

No, I don't consider it fun either. OTOH, it's very quick and trivially easy, so that makes the lack of fun doing it irrelevant. in comparison to copying 1 .jar file to the server accessing oracle from php is not quick.

Re:In defence of PHP

[LittleDobbs]

So it is totally pointless for Java, or for that matter PHP, to protect against buffer overflows in the language? I didn't say that nor do I think it. I think that no language should not be used as a crutch for improper security and that assuming your language is take care of security is not really the best practice.

Especially when PHP's biggest market is inexperienced programmers So the real problem here is inexperienced programmers not the language, which btw I would not encourage for inexperienced programmers. OK I'll give you there are some problems with the language but nothing in MOB has yet been something that PHP 5 hasn't addressed, or good programming could take care of.

mysql functions which are just imported straight from C. No other language is so crazy as to do that. Most of the functions are imported straight from C. That's how the language started as a big C wrapper that made a web page easier then doing CGI with just C. Again not for the faint of heart even though it's marketed as such.

Re:In defence of PHP

[LittleDobbs]

I really shouldn't reply to this troll bait but I don't even get what you are implying. That I don't know anything about PHP, COBAL, Python or Ruby. Which one????? Oh and yes you are right I don't now anything about COBAL and very little about Python and I think I'll keep it that way.

Re:In defence of PHP

[Goaway]

So the real problem here is inexperienced programmers not the language

So do you have a trick to make all programmers suddenly experienced? No? Well, how about we have programming languages try to catch their worst mistakes in the meanwhile?

Re:In defence of PHP

[LittleDobbs]

So do you have a trick to make all programmers suddenly experienced? No? Well, how about we have programming languages try to catch their worst mistakes in the meanwhile? Actually yes there is trick it's called a QA department which actually improves the quality of the programmer over time. As an equal argument we should all use IE 6 because it renders poor HTML better then Safari. No that's not correct :-) Let me guess you are C hater as well as a PHP hater. Never mind the fact that language of choice is probably written in C. My original point is that it's not just a matter of picking the "best" language. If you already have a code base in one language it's hard to justify spending the money to switch. It's much easier to just fix the code you have in hand.

Re:In defence of PHP

[Goaway]

Actually yes there is trick it's called a QA department

Yes, lots of people writing code in their parents' basements have a QA department. Brilliant idea.

Let me guess you are C hater

I have written hundreds of thousands of lines of code in C. It is one of my favourite languages.

My original point is that it's not just a matter of picking the "best" language.

No, it's about not picking the worst language - in this case, PHP.

Re:In defence of PHP

[LittleDobbs]

Yes, lots of people writing code in their parents' basements have a QA department. Brilliant idea.

Thank you for proving my point. It's kids in the basement not the language. Or wait do you fall in to that category

No, it's about not picking the worst language - in this case, PHP.

So basically yeah. You are in your parents basement. How can you determine the point I am trying to make? You can make your own point but you can't tell me mine.

Tell you what. Go get a job as programmer in a shop that already has a working product then come talk to me.

Re:In defence of PHP

[Goaway]

So your entire argument is to blame the users instead of the product?

And I am ignoring your "existing codebase" blathering because it is quite frankly not an interesting discussion in any way. So you're already stuck in the bog due to making a bad decision at the start - what does that have to do with the merit of one language over another?

Re:In defence of PHP

[LittleDobbs]

So your entire argument is to blame the users instead of the product?

EXACTLY. If you stick a fork in toaster the you get shocked. If you can't program or do security audits, which BTW hardened-php will do if you pay them, then you risk getting hacked.

If you use Windows 95 to browse the Internet you risk your computer being compromised.

Like I said before get a job and you will understand the argument. The quality of the language has nothing to do with the size of the paycheck. If anything it's the opposite because there tends to be less demand for the newest language and newest technologies.

Re:In defence of PHP

[Goaway]

I guess you simply are a hopeless elitist, then. I see no reason to continue the argument.

Re:In defence of PHP

[@madeus]

i did a lot of testing [ emphasis added - due skepticism displayed ] in my company that showed that creating large html forms from database content in php is 120% slower than in java. While the VM's used won't have identical performance in all areas, and neither will the database libraries, your claim does not count for a hill of beans, not least given the following:

ever tried to access an oracle db from php? not fun I don't find doing "./configure --with-oracle=/opt/path-to-oracle/" or indeed just copying a module across (if the hooks are already there) all that hard TBH.

in comparison to copying 1 .jar file to the server accessing oracle from php is not quick. The only part that's any difference is having to install the Oracle libraries is if you are compiling support into PHP from scratch (i.e. with '--with-oracle='), otherwise it's still "just copy a file across".

If indeed you are building Oracle DB support from source, you'll have to use Oracle to install the libraries so you can link against them of course (the only extra step), but that requirement - and the fact that the installer is a complete PoS is of course entirely Oracle's fault. "apt-get install php5-mysql" (or indeed / "cd /usr/ports/databases/php5-mysql; make install") FTW.

Re:In defence of PHP

[Bastard of Subhumani]

I really shouldn't respond to newbie idiots, but here goes: One, you clearly know so much about COBOL that you can't even spell it. Second, it's = it is. Seems you don't know English either.

Re:In defence of PHP

[Bastard of Subhumani]

I for one do not wish to randomly hire new programmers

That's alreight, janitors aren't expected to do that.

PHP taint what it should be

[atherix]

We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct. Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design?

Maybe. PHP is a wonderful interpreted language that makes creating a web application easy. The biggest problem with PHP are the entry-level programmers who don't understand the beast that is web programming.

Many PHP programmers don't understand the number one rule of secure web programming: All user data is evil. Anything that comes from an HTTP request can not be trusted. Heck, I don't trust it even after it has been stored in a database table or the file system. I would love to see a Perl-ish taint mode built into PHP that tells the programmer "This data has come from an insecure source. Please don't eval() it or unserialize() it or write it to disk. Cheerio."

Re:PHP taint what it should be

[Unknown Relic]

Well then, you'll be happy to know that Wietse Venema from IBM Research put in a proposal for taint support in PHP a couple months ago. I'm not sure if anything has come of it as there was a fair amount of concern that it would turn into another "Safe Mode" debacle, but from what I remember his plan was to essentially start work on a proof of concept implementation early this year and then take it from there.

Re:PHP taint what it should be

[Anonymous Coward]

The PHP developers lack the expertise to implement a taint mode anyway.

Re:PHP taint what it should be

[Anonymous Coward]

Well, they do lick Zonk's taint every day...

Re:PHP taint what it should be

[bitserf]

I wouldn't really blame the programmers for shortcomings in the platform.

The biggest problem with PHP is that it doesn't encourage adopting best practices in designing secure web applications, which is really inexcusable in this day and age.

The core developers are pretty much incompetent, they've yet to convince me they understand security issues, or modern language design. I'll never forget the debacle where they had a presentation proclaiming their version of Rails' ActiveRecord - Except that it was not possible to implement in PHP, with the syntax they presented, even in PHP5. If you don't even know your own languages' syntax/features - You're pretty much rubbish in my book.

Really, I don't trust PHP as far as I can throw it. addslashes() anyone?

Be Prepared?

[Mikenotmike]

Since properly coded PHP is still useful in many applications, what would be the best book to use as an up to date reference manual for the most secure method of coding with it?

Re:Be Prepared?

[SimHacker]

The Python reference manual.

Seriously: So what if "properly coded PHP" is still useful? It's not as useful or as easy to properly code as other languages, so why do you persist in using an inferior, defective language like PHP? Properly sealed lead and asbestos are "still useful" in constructing new houses, but you certainly should not use them! The fact that something's "still useful" does not negate the fact that it's still foolish to use it, if you have a better alternative.

-Don

Re:Be Prepared?

[Mikenotmike]

Then what's your ajax/web2.0 recommendation, currently I'm reading a peral/cgi book and another perl database (mysql) book, but from what I understand PHP does the whole ajax thing in a more fluid manner, is this incorrect?

Re:Be Prepared?

[brezel]

but from what I understand PHP does the whole ajax thing in a more fluid manner, is this incorrect? yes. php has nothing to do with javascript.

Re:Be Prepared?

[Anonymous Coward]

Because ... straight people don't ... use ECMAScript? WTF is wrong with you, bigot?

Re:Be Prepared?

[larry bagina]

ajax is a combination of client side javascript and server side code (that returns xml, text, json data, etc). PHP can be used, but it doesn't have any magic advantage over cgi, perl, ruby, python, or any other language.

Re:Be Prepared?

[LittleDobbs]

Not entirely true JSON extension does give you a javascript object and is very easy to use. But to the defense of the other languages most have plugin/modules/frameworks that take care of this as well.

Re:Be Prepared?

[aymanh]

Essential PHP Security is what you are looking for. The book covers a wide range of attacks and how to deal with them. In addition, the website has a couple of sample chapters so you can take a look and see if you like it.

Re:Be Prepared?

[akamm]

Pro PHP Security (published by APress). I believe it to be more comprehensive than Essential PHP Security... it gets quite detailed.

Re:Be Prepared?

[Bastard of Subhumani]

How much detail does it take to say "USE SOMETHING ELSE!!!"?

Re:Be Prepared?

[mangu]

It's not as useful or as easy to properly code as other languages

That depends on your application. I use Python for a lot of stuff, it's in fact the language I use most of the time.

But when you are coding a dynamic html site, there is no better alternative to PHP, at least not one that's so quick and easy to code. PHP performs admirably for the one task for which it was designed. It was designed in the same spirit of Python, that simple things should be easy and difficult things should be possible.

Being easy to code doesn't mean that bugs are impossible. For instance, I recently wrote "A = B" in Python when I really meant "A = B[:]", it took me a while to find out why the data was changing apparently at random.

However, maybe PHP is too easy, maybe it lets people who aren't properly trained on security issues to create websites that are exposed to the world. Imagine if a Python newbie were creating a website and ran an eval command on something the user typed. Would you blame Python if someone typed "import os; os.system('rm -Rf /')" in that field?

Re:Be Prepared?

[larry bagina]

PHP 5.2.x includes standard json encode/decoding (if you don't mind the limitations). For earlier versions, json.org lists 6 ways to do it, most of which require recompiling.

Why not use a lovely PHP FrameWork then?

[SpzToid]

Why not use a lovely PHP FrameWork then? Like, um, say, Drupal?

- - - -

You can't be ahead of the curve, if you're stuck in a loop.

Next Month...

[bill_mcgonigle]

Month of Shooting Fish in a Barrel

Seriously, when does the Month of Oracle Bugs make its return? Or did the Month of Bugs folks simply chicken out when Larry Elison showed up at their house with a samurai sword?

Re:Next Month...

[Cheapy]

No, that's RMS who has a samurai sword:
http://www.xkcd.com/c225.html

Is there an alternative?

[harry666t]

We can use Ruby on Rails.

perl is very good at text processing as well.

Are there any PHP-to-C++ translators? If the bugs are sitting in the PHP interpreter itself, it might be safer to translate and compile the code.

"Only perl can parse Perl" - but maybe there are alternative PHP parsers/interpreters?

Re:cocks

[Anonymous Coward]

That's Zonk's dream. He's probably whacking to the thought of that right now...

Why MOPB Matters

[gantry]

I have just analysed the last month's script kiddie attacks on my web server. 71% of them were to php-related URLs. When I first went through this exercise some years ago, the overwhelming majority of attacks were URLs related to IIS. The significance of this change cannot be overestimated.

Yes, a lot of the problems are sloppy coding, but too many are in the PHP core. How many web pages use the PHP-array-specific query-string
    ?foo[]=bar
- not many, you might think. How many use a PHP nested array
    ?foo[][][][][]=bar
- quite an unusual structure, you might agree.

The real stinger is that PHP will let this array be as deep as an attacker likes - and it's the same for a POST as for a query string, so there's no practical limit. An attacker can exhaust the space available for the stack, with several adverse consequences. This bug has a lot in common with the gravest bugs in PHP's history, in that it is a mistake in PHP's input processing: in this case, PHP trusts the sanity of user input. According to MOPB, Zend's attitude to this bug is "won't fix".

The arrogance of this attitude is breathtaking. PHP is now the most insecure package on my internet server, probably surpassing the old BIND 8 in the frequency and gravity of its exploitable bugs. I sincerely hope that Zend will get its act together and make security their number one priority. The predominance of PHP on the web is not theirs as of right - if they do not act, then either their product will be forked, or an alternative will take its place.

The nested array bug is described here:
http://www.php-security.org/MOPB/MOPB-03-2007.html

Re:Month of bugs, will it change things for better

[mrbluze]

I for one welcome our new month-of-bug overlords.

Best book to learn from

[matt me]

If you want to code well, you're best reading the Camel Book [sic].

You have never used PHP

[mangu]

Having never used PHP but heard of its many security problems...

You would hear of the many security problems of any language that's widely used in the internet. It's not that PHP is so insecure as that, the problem is that it's more exposed, so it needs to be more secure than other languages.

Part of the problem with the public image of PHP is that it's a purely "commercial" language, it lacks the nerdy appeal of Ruby or Lisp, for instance. Most of the comments you'll see here in Slashdot bemoaning PHP's shortcomings come from people like you, who never used PHP but are used to hearing about its security problems.

I use the language that's best for a given application. I use Perl to extract data from text files, Python for engineering programs, C for number crunching, PHP for getting user input in web interfaces, SQL to store the data. However, any time I try to explain here in /. why I don't use Ruby, I get modded down into the basement, while you get modded +4 for criticizing PHP. That's how a herd mentality works, don't try to get your facts from experience when you can just learn by hearing what other people say...

of Red Hats and Yellow Pants

[Anonymous Coward]

As the Month of Apple Bugs (as well as others) prove, OhitSuX appears to be defective by design.

MOAB proved security through obscurity is not security. I would look forward to a "Month of Linux Bugs"... but it seems EVERY month is given that honor.

Here are the problems..we will fix if you Pay!

[Anonymous Coward]

How unethical is this!!! Here are the security problems with PHP. We have not reported all of them to the PHP people but we will fix it for you if you pay us. If not, well here is a nice encyclopedia of PHP problems for you bad guys to take advantage of. Sounds a bit like extortion to me.

Programmers need to be aware

[Wann_2275]

PHP is a scripting language that can be run as either a CGI application or as an integrated Web server module. Regardless of its mode of execution, the PHP interpreter has the potential to access virtually every part of the host -- the file system, network interfaces and etc. Consequently, it has the potential to cause a lot of damage. The programmer needs to be aware of everything that can go wrong at any time during the program execution,in order to prevent attacks from adversaries. And yes this is a formidable task. Software getting so complicated very fast. But somehow, ussually knowledge about the weaknesses of a system and the common modes of attack can go a long way toward increasing its security. Same goes to any other piece of software.