In this new post to his blog Stefan Esser looks at cross-site request forgeries and how they can be prevented in PHP 5.3 by two things - the request_order directive in your php.ini and by not using $_REQUEST anymore.

Although PHP 5.3 is still in alpha stage and certain features like the PHAR extension or the whole namespace support are still topics of endless discussions it already contains smaller changes that could improve the security of PHP applications a lot. [...] With request_order it is now possible to control in what order $_REQUEST is created and what variable sources are taken into account. This finally allows removing cookie data from $_REQUEST without removing them from $_COOKIE also.

He explains why the use of $_REQUEST can lead to such problems (and security holes) and notes that its use makes overriding an application's GET or POST values as simple as adding a cookie. There's even a method for creating a Denial of Service attack against a site using $_REQUEST like this. He points to an example similar to this that happened with phpMyAdmin a while back.

His recommendation?

Once PHP 5.3 is out it is recommended for hosters to set request_order to "GP" on all the servers running arbitrary PHP applications to protect applications [and] application developers on the other hand should finally move away from using $_REQUEST for user input.

In a new post, Tobias Schlitt looks at how to send HEAD requests right along with the rest of your payload with the ext/curl extension for PHP.

I recently wanted to perform a HEAD request to a file, after which I wanted to perform some more advanced HTTP interaction, so CURL was also the tool of choice here.

He started with the (slow?) command line to get the parameters right before moving into PHP. After picking out the right ones ("curl -I -X HEAD http://localhost/admin/") he transfers them into a series of curl_setopt calls that specifies a HEAD request type and no content to send (with CURLOPT_NOBODY).

On his ThisLab blog, Fred Wu has posted some quick benchmarks comparing some of the popular frameworks out there - Ruby on Rails/Passenger versus CodeIgniter/Kohana.

Last few days I have been playing with Ruby and Rails, again. Today, when someone was asking on a forum about the efficiency of web frameworks, I thought I'd give the few frameworks I work with some more benchmark testing.

His benchmarking is based on basic "Hello World" page requests for each of the frameworks. His results were interesting with CodeIgniter coming out with the fewest number of requests responded to (per second) and Rails coming out on top by a margin of about eighty or ninety over CodeIgniter/Kohana.

Michael Girouard has posted his 10,00 foot view of the typical structure of an Model/View/Controller application (and framework) and how a page request is handled:

In my previous article, I announced that I would be documenting the process of developing a simple MVC framework. In this post I will go into a little more detail about each of the specific components of our MVC and will discuss the series of events which occur each time a page loads, otherwise known as the page load scenario.

He talks about how URIs work, the role of mod_rewrite, several of the objects involved (like the Front Controller, Request, Route and View) and how they all fit in with the custom Models, Views and Controllers the user could define.

As mentioned on the Zend Developer Zone, there's a new tutorial posted on the IBuildings blog (by Lineke Kerckhoffs-Willems) about performing some multi-threading magic in PHP with the help of cURL.

Each PHP request is a separate thread. There are some workarounds like using pcntl_fork, starting multiple commandline php processes using the exec command or even using ajax. Another possibility is using the Curl library. Besides the basic functions described above Curl offers the "multi" functions for retrieving content from several url's at the same time.

Examples are included showing how to make these "multi" requests via PHP's cURL support (calling URLs with a "seconds" value on the end).

On his blog today, Stoyan Stefanov has a howto posted on a trick he figured out to get a PHP script to grab data from multiple resources at one time - with cURL.

The basic idea of a Web 2.0-style "mashup" is that you consume data from several services, often from different providers and combine them in interesting ways. This means you often need to do more than one HTTP request to a service or services. [...] Using the curl_multi* family of cURL functions you can make those requests simultaneously. This way your app is as slow as the slowest request, as opposed to the sum of all requests. And that's something.

He includes example code that loops through a given array of resources and executes the fetch, brining the results back into a result array. To illustrate, he also includes two types of examples of fetching content - one for GET and another for POST.

On the PHP in Action Blog, there's a this post that shares some tips for testing your web applications with some simple tests.

I just started listing the techniques I've learned when writing tests to exercise the web interface of a PHP application. This is from my experience and my personal preferences; it's not the final word or necessarily right for everyone.

He suggests:

• Use SimpleTest's Web tester if you can
• Test the web output using regular expressions
• Use element IDs or names to test links, forms and fields
• Log HTTP requests in the application

In one of his recent blog entries, Brian Moon takes a look at what he considers the "proper use" of the PHP superglobal $_REQUEST (as brought on by a thread on the PHP internals mailing list.

I have seen more than one person make the following logic mistake: I may get data via GET, I may get data via POST - Ah, I should use $_REQUEST as it will catch both.

Brian points out the error - cookies aren't in $_REQUEST so improper handling of those values could lead to cookie data overwriting GET/POST data from $_REQUEST. Several of the comments on the post also warn against improper handling of the values, noting that doing so could lead to holes open for attacks (like session fixation).

PHPBuilder.com has a new article by Hillel Aftel about his method of choice for securing the data that you send over the GET string when moving things around on your site.

In this article I'm going to show you how you can use PHP to encode your data for transit. Most importantly, it will be done in a way that makes the data decodable, and therefore much more usable, by the receiving page.

His encryption method - sending everything in a single string and modifying the scheme each time - uses static pairs of values (of your choosing) to "encode" the outgoing string. It actually consists of three different files: the script itself, a single-use script that makes the third file, an include file to handle the conversion back from the encoded results.

Ligaya Turmelle shine up and shows off a streams gem that she rediscovered - a simple method of sending a POST request and getting it's response:

Was reminded today of a gem from the streams extension - sending a POST message and getting its results. We could do it using cURL or sockets - but why work that hard. Being lazy does have its advantages after all.

The example she includes is one from the manual, showing how to take the array of data and push it out to the remote site with a few simple calls (including stream_context_create).