Slashdot Mirror

in php its no big deal to make sure that anything you stuff in a db is safe - just do an $valueToStore = htmlentities($valueFromPoster). So either do the same in perl, or convert to php.

The PHP documenation stopped recommending the use of Apache 1.3 a long time ago.

The no PHP on Apache2 FUD is just a meme that won't die, not the fault of the PHP folks.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

I read the vulnerability which links to the sourceforge.net page that has the source code of this "library". It's a PHP script that you include() into other PHP scripts to use the functions/methods defined. The developer of this PHP script used eval() in an incorrect manner.

Unless you have another article that shows the PHP XML-RPC Functions to be vulnerabile, this is not a PHP vulnerability.

---John Holmes...

Yeah and Tobias Schlitt of Pear posted about it on the same day in his blog: http://www.schlitt.info/applications/blog/index.ph p?/archives/349-PEARXML_RPC-Security-vulnerability !.html and other PHP software, like Bitflux http://blog.bitflux.ch/archive/2005/06/29/bxcms-1- 2-1-security-bugfix-release-codename-not-our-fault -2.html, was patched on June 29th too.

http://www.php.net/ had a news entry about the issue last week. So everyone should have patched their pear-libs in the meanwhile.

b4n

Get http://pecl.php.net/package/APC and you have an open source opcode cache.

There're some others - some of the with optimizers. And if you have the money you can also get the Zend stuff.

b4n

Paul Dubois' last edition of MySQL covers, among other interesting topics, using Pear::DB with placeholders.

Paul Dubois' last edition of MySQL covers, among other interesting topics, using Pear::DB with placeholders.

I have it shortened even more using a Firefox keyword. The URL is http://www.php.net/%25s and the keyword assigned is php. When I need something, I just enter:

php strings

and it takes me right there, and with seven fewer keystrokes than you, making me more efficient. :)

Hell the php .chm is wonderful as well.

When I started developing in php and mysql I went out and bought "Open Source Web Development with LAMP". It was recommended, and apparently was very helpful. After an hour, put it on the bookshelf and went to php.net, and haven't looked back since. Anything that is in these books I can usually figure out myself with the help files, and anything I cannot figure out myself usually isn't in the book (though there is always a web site somewhere with example code that does exactly what I want).

I'd have to agree, my perfect PHP book would be one where they just dumped all the PHP documentation into it... and magically let me search it like I can on the website with user comments: PHP Manual

How about you learn the language before you speak out of what google news and fellow slashdotters tell you?

Saying that there was a worm that only affected PHP forums is only a half-truth, at best. It only affected a single PHP based forum, not every PHP forum made in existance. The flaw there was a hole in the software, NOT a hole in PHP. Have there been holes in PHP? Of course, there's hole in everything else, too. The exploit was not in PHP, it was in some software that's coded in PHP. Using your thinking, that's like saying C is a horrible language because if you don't know what you're doing, there's a chance of a buffer overflow.

From "A Note on Security in PHP":
" A recent Web Worm known as NeverEverSanity exposed a mistake in the input validation in the popular phpBB message board application. Their highlighting code didn't account for double-urlencoded input correctly. Without proper input validation of untrusted user data combined with any of the PHP calls that can execute code or write to the filesystem you create a potential security problem. Despite some confusion regarding the timing of some unrelated PHP security fixes and the NeverEverSanity worm, the worm didn't actually have anything to do with a security problem in PHP."

The phpbb developers are not stupid, they are competent people. Yet, there was a hole. It happens, no one is perfect.

I'm quite certain that JSP/Tomcat can be just as insecure if you code it wrong. Same with ASP. Or, gasp, anything.

I would have moded insightful instead of funny. I'm a fan of php, and one of the reasons I like it so much, is their website. Its a very complete reference to the language, and the user comments included with each function are inavluable. In fact, one of the best things about the website is its ease of use. If I'm trying to remember exactly how a function works, its as easy as http://ca.php.net/function

Dont buy a book about PHP AND MySQL.

Seriously, buy one for each one of them.
Then, when you've bought those two, you can stack them under your laptop and type in:

http://www.php.net/
http://mysql.com/doc/

Ready to go!

According to the PEAR Development mailing list, PayPal is in fact willing to push some changes back to the community. According to this Zend press release, PayPal paid Zend, to make improvements to PEAR::SOAP package 0.9.0.

So for all of you PHP 4 developers, you might just owe PayPal for your ability to make SOAP-based web service calls.

on a related note the php manual already has that feature (example) and at times its quite helpful.

Or you can use http://pear.php.net/package/Translation2 which also handles gettext Note that using gettext gives you huge advantages as you can then use standard tools to manipulate the translations...

I did this in 2003 for a CMS+ecommerse system I did for a company. You had Smarty templates which had things like {productstr1} in them. The text strings were referenced by language and string ID, and if the string didn't have a specific version for your language it defaulted to English. This string was loaded from the database in a preparse plugin and was cached in a per-language directory. It worked ok, a bit kludgy but sufficient to get the job done.

Damien

I haven't tried any of them, but PEAR has a number of packages for dealing with internationalization. You might want to try looking there for insight.

Yes, the concept of many people speaking different languages has been around six months to a year at most. It's far too new a concept for something like PHP to have dealt with.

What's the problem? For the dynamic data, store extra fields/rows, for the static text use multiple templates or the gettext functions, and for the images, use separate subdirectories like /en/images, /de/images, etc.

This is really basic stuff. It's like saying "is the concept of 'adding' too new for PHP to have dealt with because I can't find an article on adding in PHP for me to copy & paste from?" Read TFM and apply common sense. That's all you need.

BTW there's already an extension for that in PECL: http://pecl.php.net/package/oggvorbis

b4n

So is this the equivalent of the PEAR library for PHP?

Using * in mysql makes no difference at all. mysql_escape_string() is a real function (hint, you're a moron), and using sprintf() is cleaner, and allows stricter formatting. How you do interpolation really is a matter of preference only, so trying to nitpick on that instance really just tells me that you're being stupid.

There is PDO for PHP 5.

Not in set theory.

The == operator in PHP has nothing to do with set theory. It's called the "equal" operator, so either it should behave in a manner consistent with equality or it should be named and written differently.

You're the one trying to convert "spam" into an integer.

Really. Tell me, where in

$a == $b

Since regexes must be quoted, there is a problem with the /e modifier which cannot be fixed.
See: http://bugs.php.net/bug.php?id=15050
It comes down to this:
$text=preg_replace("/(.*)/e","'\\1'",$text)
will never work right if $text contains the character ", and
$text=preg_replace('/(.*)/e','"\1"',$text)
will never work right if $text contains the character ',
because a backslash is introduced.
So you have the write a function to remove the \ and put that function in the replacement string.

And plenty of other features are missing that Perl has with m//, s///. For instance, m//g.

In general, Perl is more reliable than PHP, and I prefer it, but PHP does have two advantages:
1. on a typical Linux/Apache system, without mod_perl, Perl spawns a process on every reequest.
2. session-handling.

Just because you use a good abstraction strategy doesn't mean you have to actually implement the code for every platform. I just write for the one that I need at the time & I can use as much platform-specific code as I want. But, having a strategy in place so you can plugin a new DB later is comforting.

As much as I hate to give up my SQL code, persistance layers for PHP like Propel and PEAR DataObject seem to be maturing nicely. DB abstaction becomes (in theory) a mute point. I'm really anxious for PHP 5 to become more widely installed so I can take advantage of these technologies that are already in production status for Java and .NET code.

== isn't broken, it's ambiguous and complex. It's also well defined and documented:
http://docs.php.net/en/types.comparisons.html

There are few if any cases where your (0 == "eggs" != "spam" == 0) case comes into play in the field. And for the cases where it might, we have the type-safe === and !== operators. Yes, it seems quirky to a programmer coming from a strongly typed language, but once you adjust, it's not a problem at all.

PHP 5.1 has a new module going in for a consistent database API. It is not an "abstraction" layer per se, however, any database with a supported driver (all the major ones already have one) can be dropped right in. Check out PDO: http://www.php.net/pdo -- more links are in the comments at the bottom, including a PDO wiki page. It is also in PECL right now and you can download compiled binaries for Win32 versions of 5.0 or higher; source is available for unix systems. The only major thing that I know of that it is lacking now is support for scrollable cursors, but Wez is working on that. My current app uses PDO and it is lightyears faster than PEARDB and ODBC. Plus it is OO based!

I agree that the manual is wonderful.

I especially like this table, which elegantly illustrates where weak typing[*] can creep up to bite you and why it is not necessarily easier than strong typing.

That the manual is so comprehensive and easy to access is also important when you constantly have to look up the names of common functions, because half of them follow C naming conventions (strcmp, etc.), half of them have prefixes (array_*), half of them follow no convention (htmlentities, etc.), and none of them are in any sort of namespace.

[*] I don't mean dynamic typing; I mean weak typing as opposed to strong typing. A language could be dynamic and still enforce the type of common sense that prevents 5 + "10 little piggies" from equaling 15.

Not that I'm bitter, of course...

mysql_escape_string is deprecated and should never be used in production code! The replacement is the hilariously named mysql_real_escape_string.

Your "not that hard" comment is rather amusing with this in mind.

When you can explain the core language and primary namespace to an interested programmer in under 30 minutes, I'll be glad to revisit the topic. Until then, Python is simple. Perl is even reasonable simple. PHP is not simple in any way, shape, or form (unless you're using the facetious Simple from SMTP, SNMP, and other horridly complex standards).

Dude, you need to provide links. I had to *gasp* Google it! ;-)

For others, PEAR can be found here:

PEAR Class Repository

The Database classes of PEAR appear to be documented here:

Database Package

Looking over the DB classes, it looks like they provide a fairly decent abstraction. Thanks Quinto, that will definitely be nice for future PHP projects. :-)

Dude, you need to provide links. I had to *gasp* Google it! ;-)

For others, PEAR can be found here:

PEAR Class Repository

The Database classes of PEAR appear to be documented here:

Database Package

Looking over the DB classes, it looks like they provide a fairly decent abstraction. Thanks Quinto, that will definitely be nice for future PHP projects. :-)

What the hell is PHP?

Probably a troll, but just in case anyone else doesn't know: PHP is a scripting language designed for generating dynamically created web pages. It functions by mixing its scripting in with the HTML, thus allowing programmers to reuse existing page designs. The scripting APIs are centered around those commonly used on Unix systems. PHP is usually bundled with Apache, so no installation tends to be required.

PHP Homepage

He also uses a regex when a simple string match will do. PHP is already programming for dummies, OP should consider giving up; there's not much more to say really.

PHP defaults to 302. See http://php.net/header.

The second special case is the "Location:" header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless some 3xx status code has already been set.

Forget about code semantics, focus instead on application development theory and techniques, application frameworks, design patterns, etc.

I personally develop in both ColdFusion and PHP along with the Fusebox framework, and have just started using the fantastic FuseBuilder tool for the design stage. The using the Fusebox Lifecycle Process (FLiP) and a design tool that works with it (FuseBuilder) ensure that clients get what they want, no hassle, no "but it should be blue with green buttons". I can't promote FuseBuilder enough, it has become the bread and butter of both my day-job and side consulting.

Damien

I've noticed that most projects done in PHP don't utilize crypted MD5, even though crypt on most OSes support it.

It's really easy to programmatically check to see if the OS crypt supports MD5. Simply pass an 8 character salt to crypt as its first argument, then check the first three characters of the output. If they're $1$, your OS's crypt library supports crypted MD5. This will work in any programming language whose crypt command sends data to the system's crypt command: C/C++, Perl, and PHP to name a few.

ASP caches compiled bytecode (tokens), while with PHP you have to pay extra for that functionality.

No you don't.

Most of the work on PHP is being done by Zend, which very much has a commercial business model.

So? The same can be said for Linux, Apache, MySQL, Sendmail, Qt, BIND, pretty much all high-profile open-source software. As a software package becomes more important, it either gives the original developers a chance to make money, or it becomes important enough to an existing company that they pay people to improve it. This is nothing new or out of the ordinary, and the possibility of forking discourages the commercial interests from not acting in the best interests of the users.

There is already http://gtk.php.net/

"Actually it started out as an apache module."

Actually, you're totally wrong.

"It stands for 'Pre Hypertext Pages'."

No, no, and no again. It never stood for that, not once, not ever. I'm not even going to dive into the rest of what you wrote, I'll just back myself up with real facts, unlike yours.

I quote:

"PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume. He named this set of scripts 'Personal Home Page Tools'."

Thanks. Now please stop trying to prove people wrong unless you know your OWN facts first.

1. Why is the first's prototype:

   resource mysql_query ( string query [, resource link_identifier] )

   while the second has its arguments reversed:

   resource pg_query ( resource connection, string query )

   ?
2. Why is "mysql" spelled out, but "postgresql" or even "pgsql" abbreviated to just "pg"?

I hate the language for its utter lack of consistency. People talk about how great the php.net documentation is but I think they have the causality reversed: those docs have to be excellent or the language would be unnavigable. I have no desire to remember 3500 core language functions with similar (but inconsistent) naming systems and a randomized argument list. Seriously, what were they thinking?

I don't think PHP is inherently bad, but the current implementation certainly is.

1. Why is the first's prototype:

   resource mysql_query ( string query [, resource link_identifier] )

   while the second has its arguments reversed:

   resource pg_query ( resource connection, string query )

   ?
2. Why is "mysql" spelled out, but "postgresql" or even "pgsql" abbreviated to just "pg"?

I hate the language for its utter lack of consistency. People talk about how great the php.net documentation is but I think they have the causality reversed: those docs have to be excellent or the language would be unnavigable. I have no desire to remember 3500 core language functions with similar (but inconsistent) naming systems and a randomized argument list. Seriously, what were they thinking?

I don't think PHP is inherently bad, but the current implementation certainly is.

The Real Solution to Perl is...

PHP (or better yet, LAMP)

You know that this is NOT a PHP exploit, this is an exploit on a poorly written application that uses PHP. You should read this note on security by the PHP team: http://www.php.net/security-note.php

With Smarty, and PHP, you could put the list in its own cached template. Check to see if the template is cached before displaying it and if not go to the database.

You can even use Smarty's html_options function to build your lists for you.

And when something changes the data for the list, just clear the cache. The next time it's needed the cache will be updated.