Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail's case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of "buried" code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby's dark magic, e.g. eval(), include(), require_once(), system() and, let's not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise… Pay attention to competing applications or frameworks - their problems may also be your problems. If you're worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters' might originate from.

Today I'm giving my first ever talk at OSCON - about PHP 5.4 (I'll also be giving my second ever talk at OSCON, about RESTful services; it's a busy day!). My talk includes some benchmarks which I thought I'd also share here. [...] This graph shows the performance of four versions of PHP (because the bench.php script that lives in the php source tree didn't appear until 5.1). The axis up the left is the time it took to run the benchmark script - so a smaller number is better news.

You can see a dramatic difference between even just the latest in the PHP 5.3.x series in the 5.4 results. There's also a table with the details of each of her 10 executions of the "bench.php" script showing the results of the time spent to run the script on four different PHP versions.

I've been watching the Destroy All Software back catalog over the last couple of months and it's really inspired me to up my TDD game. I'm still fairly new to TDD, I've written tests for a long time, but never really let it lead my development…

He talks about the testing tool he uses and some of the ideals he keeps in mind when developing his tests. He also comments on testing isolation, speed of execution, the "fail fast" idea as well as integration testing and continuous integration.

Sometimes we use exceptions to manage the flow of our scripts. I imagine that the use of exceptions must have a performance lack. Because of that I will perform a small benchmark to test the performance of one simple script throwing exceptions and without them.

His (little) benchmarking scripts are included - both looping 100000 times, one throwing an exception and the other not. The results were pretty obvious - the memory usage was about the same but the speed was about ten times faster without the exceptions (in PHP 5.3). In PHP 5.4, however, the numbers were closer as far as time to run. Obviously, unless you make super heavy use of exceptions, you're not even going to come close to something like this (micro-optimization anyone?).

Yesterday Kohana 3.1 RC1 has been announced and tagged. I think now it's time to get familiar it. In this post I'm going to examine the refactored request execution workflow. Let's start with the bootstrap mechanism.

He notes that most of the changes don't happen at the boostrap level. They're more behind the scenes than that, with changes in how it works within the HMVC design pattern. He talks about the changes in the Request objetct's constructor, factory and client methods. He also includes a full flow of a request for a sample welcome controller, describing the steps it falls into and a list of classes that the Request object may have used.

Symfony is a powerful PHP Framework. One of the features that I have really taken advantage in my last project is request filtering or execution filtering. Request filters allow you to inspect the request before and after the main logic is executed. Why would one want to do this? There are many reasons to implement request filtering.

Here's his three articles:

• Execution Filters
• Execution Filters:Add objects to global environment
• Execution Filters: Controlling output

You can find out more on their practical use in this section of the Symfony site.

Most people use the 'easy' mode - in this mode when we issue multiple requests, the second request will not start until the first one is complete. This is known as synchronous execution, and this is the one we normally use. [...] In [multi] mode all requests can be handled in parallel or asynchronously. And it can be quite handy and time saving on many occasions.

He gives some code examples of how to use the library to simplify the curl connections and requests and pass the result off to a callback when it's done. His more practical example shows how to search for a set of terms on Google and return the results for output.

If you exclude C and its child C++, the most popular programming languages in the world are Java and PHP, which power most of the dynamic web. I have working experience with PHP and for academical purposes I am deepening my knowledge of Java, thus I'd like to point out similarities and key differences between these two languages. Every language has its pros and cons, so there's no absolute winner here.

He briefly covers their history, java's static versus PHP's dynamic typing, how they both handle objects, their execution plans and how easy they are to deploy when it comes to general applications.

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.

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.