PHPBuilder.com has a new article from Jason Gilmore on security in command-line applications posted today and what you can do to help protect your scripts from unwanted system command access.

In this tutorial, I'll show you how to securely execute a variety of system-based commands via a PHP script, demonstrating how to build web applications that can tightly integrate with both the operating system and third-party software.

He mentions the proper filtering of input strings (user input), how it can protect your and your application as well as a few examples of using the PHP execution functions (like exec or passthru) and how to apply the shell escaping commands (like escapeshellarg) as a first layer of security.

Debugging resources being used by your script has always been a pain, and many developers have come up with their own libraries to handle the process. Ryan Campbell has his own entry in the category - the PHP Quick Profiler.

In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review.

[...] To reduce this repetition of checking the same requirements over and over], we invested some time creating something we've called the PHP Quick Profiler-we call it PQP for short. It's a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code.

The post gives several screenshots of the tool in action and code to get you up and running quickly. The Profiler can keep track of memory usage, "runaway" includes, execution time and database activity. There's also an online demo so you can try it out yourself.

Here's the link to the latest version's download.

Brian Moon had a problem - one of his cron jobs was lasting for much longer (hours!) than it should have been. He tweaked, tested and debugged the script and finally came down to a call to in_array, something he comments on as being "quite slow".

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

Nessa has set up a post in an effort to help budding PHP developers out there with some of the most common problems they might come across in their work and how to handle them a bit more gracefully with error handling:

I'm going back to the basics here, you know, when you wrote your first PHP script and saw an ugly-ass error message pop up on your screen? Error messages are the best tool a programmer has.

She talks about how to set up the error reporting first, making sure that you're getting things up and useful. From there she describes some of the common errors that you might see including:

• Parse errors
• MySQL Result source errors
• Stream errors
• Max Execution Time errors

Check out the rest of the post for more types.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.

As reported here on Secunia (as discovered by shinnai), there's a code execution vulnerability in PHP's glob function:

The vulnerability is caused due to an error in the handling of an uninitialized structure inside the "glob()" function. This can be exploited to execute arbitrary code, which may lead to security restrictions (e.g. the "disable_functions" directive) being bypassed.

The vulnerability is confirmed in the 5.2.3 win32 installer. Other versions may also be affected.

The issue is marked as "less critical" and can be avoided easily by only allowing trusted users the correct permissions to execute PHP code on the server.

TCExam users will definitely want to pay attention to this latest advisory posted by Secunia detailing a PHP code execution and cross-site scripting issue that's been found:

rgod has discovered two vulnerabilities in TCExam, which can be exploited by malicious people to conduct cross-site scripting attacks or to compromise a vulnerable system.

The two issues is related to two different inpus not being handled properly - the mishandling of the SessionUserLang cookie and the _SERVER[SCRIPT_NAME] value. Neither of these are being sanitized.

This issue effects users of the TCExam 4.x series but a new version, 4.1.000, has already been released and made available for download.

According to this note from Christian Stocker on the BitFlux blog, the upload progress meter (using the new file upload hooks introduced in recent PHP versions) has finally been included, officially, into PECL.

After some tweaking, code improvements and remote code execution vulnerability fixes, I finally put the uploadprogress extension into PECL.

Windows users might be out of luck for a while though, since Christian's not pursuing binaries for the package. However, the source is there, and anyone is more than welcome to try...

According to this new advisory on the Hardened-PHP project's site, there are some issues with the Zend Platform product that could cause a number of security issues becaue of malformed session IDs.

During the development of suhosin, which is our new PHP protection module, several compatibility tests with binary 3rd party PHP extensions like the Zend Platform and the Zend Optimizer have been made. When testing the session protection features of suhosin, we discovered that the session clustering system, which is shipping with the Zend Platform is vulnerable to several different attacks.

They mentions a few things a potential attacker could use this issue for, including crashing the session daemon, remote code execution, and being able to view and write files of their choice (like session files) to execute malicious code.

The details are listed out, but a "proof of concept" isn't published for this exploit. Thankfully, Zend has already provided a patch for the issue which can be downloaded at Zend's website (an upgrade to version 2.2.1a).

The International PHP Magazine has posted the results from their latest poll, this time asking which one of their options is the most dangerous kind of problem an application can have.

Options included "remote code execution", "SQL injections", and "file system attacks". Topping the charts, and almost typing for first place are "remote code execution" and "SQL injection", with SQL edging out the remote code.

The majority believes that 'SQL Injection' is the most common PHP attack as it garnered 33.6% of the votes. The PHP attack 'Remote Code Execution' scored 30.9% of the votes. The options 'File system attacks' and 'Cross-site Scripting' bagged 10.9% and 8.2% respectively. Not many people seem to consider the existence of any other PHP attack as the option 'Others' polled a dismal 0.9%.

Their latest poll goes with a different subject, asking readers to vote on which of their options is the best way to speed up a site. Check it out and cast your vote today!