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.

Recently, Cormac posted this look at a method for lazy loading on variables in an object with the magic __get method.

I used the magic method __get() to load the images into the [Product] object when they were needed. __get() is called whenever something tries to access a variable that is not set or publically accessible, so basically I used that to load the images whenever some other piece of code tried to access Product::images.

He includes a quick bit of code that fires off an internal private method for the class that loads up the images. In his example, if they're already loaded, it never gets called.

For a recent REST web service project, Lorna Mitchell had to put together a server for the remote clients to use. She started with a GET request then moved to handling a POST request then to a PUT request - that's where the difficulty came in:

PHP doesn't have a built-in way to do this, and at first I was a little confused as to how I could reach this information. It turns out that this can be read from the incoming stream to PHP, php://input.

Pulling from that stream gave her the raw data she needed (nicely urlencoded too) that she could parse out and use. She includes a simple example that has a check for the REQUEST_TYPE in the _SERVER superglobal to see how the request should be handled (PUT versus GET).

Padraic Brady has written up a post on how he implemented conditional fetching (GET) as a part of the Zend_Feed component of the Zend Framework.

You see, by default, Zend_Feed is stupid. It will blindly drag in whatever RSS you point it at, parse it, present an accessible API (which is largely an abstract API across PHP DOM), and then merrily sit back while you are driven demented. There is a problem in blindly fetching RSS and parsing it - RSS feeds from a huge number of online sources only change rarely. The rest of the time the feed is unchanged.

The key is in the "Last-Modified" header data of the remote file (and ETag). He shows how to use this knowledge in a simple example - pulling data with a ZFBlog_Aggregate class and dumping the contents into a database table. This code checks the return status for a 304 ("Not modified") and closes out the connection if so. Otherwise it grabs the content and updates the database with the most recent fetch times to compare to the "Last-Modified".

On the PHP in Action blog Dagfinn Reiersol shares a method to send messages across a POST request that's followed by a redirect (versus a simple GET where it can be in the URL).

When processing a GET request, you can display whatever messages you want. The most simplistic way is to echo them directly; or if just slightly more sophisticated, set it in the template that's about to become the web page. When processing a POST request that is to be followed by a redirect, you can't do that. The response (redirect) sent back to the browser does not have any text or HTML content.

He points out two different ways to handle the problem - either manually append the message to the URL you're redirecting to or (a bit better method) store it in a session variable and remove it once its done. Several frameworks call this a "flash message". He gives examples of how to set this in two popular frameworks - Zend Framework and CakePHP.

On the PHP in Action blog Dagfinn Reiersol shares a method to send messages across a POST request that's followed by a redirect (versus a simple GET where it can be in the URL).

When processing a GET request, you can display whatever messages you want. The most simplistic way is to echo them directly; or if just slightly more sophisticated, set it in the template that's about to become the web page. When processing a POST request that is to be followed by a redirect, you can't do that. The response (redirect) sent back to the browser does not have any text or HTML content.

He points out two different ways to handle the problem - either manually append the message to the URL you're redirecting to or (a bit better method) store it in a session variable and remove it once its done. Several frameworks call this a "flash message". He gives examples of how to set this in two popular frameworks - Zend Framework and CakePHP.

Ben Ramsey has recently blogged about some of the research and bit of development that he's done to add "more correct" functionality to the Zend Framework for working with RESTful interfaces - proper PUT and DELETE support.

I've recently been wrapped up in an effort to design and implement a RESTful API using the Atom Protocol for a project at work. We are using the Zend Framework as the underlying framework for the project, so, in order to follow the Atom Protocol, I needed to support the HTTP methods PUT and DELETE

Since the Zend Framework has been playing such a prominent role in the development, he's been digging into the Zend_Rest_Server component code and isn't too happy about its support for PUT and DELETE. As a result, he's proposed methods that might help resolve things such as isGet, isDelete, isOptions and getEntityBody. He' even created a patch to make the needed changes.

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.

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.