Guyub – Konsultan F/OSS

I just finished my PHP in the Enterprise talk at ConFoo, Slides are available here: PHP in the Enterprise – ConFoo March 2010

PHP 5.2.13 has been released. The announcement is here and software is on the downloads page. At the same time, PHP 5.3.2 RC3 is available for testing, see http://news.php.net/php.qa/65489. There are only a few days before the final PHP…

Three years ago the Hardened-PHP project organized the Month of PHP Bugs. During one month I disclosed more than 40 vulnerabilities in the PHP interpreter in order to improve the overall security of PHP. In the history of PHP this event has been one of a kind. But now, three years later, my company SektionEins GmbH will continue in the same spirit and organize the Month of PHP Security. Our preparations are not finished yet, but here is a sneak preview of what it will be.

The Month of PHP Security will take place in May 2010 and will be very different from all the previews ?Month of Bugs? or ?Week of Bugs? events. You can think of the Month of PHP Security as a conference without a conference. This means around the 1st of March we will send out a call for papers in order to collect the best advisories, the best research and the best articles about PHP security. We invite everyone from the PHP and from the security community to take part in this event.

The basic idea will be that during May we are planning to release (at least) one advisory or one research paper or one article about PHP security topics that were submitted to the public. And in the end of May our jury will select the best X submissions and give out prizes. We are still in the process of selecting good prizes and would be happy about more sponsors. Therefore: If you consider this event to be a good idea to improve the security of PHP and want to sponsor prizes, do not hesitate to contact us at info@sektioneins.de.

The accepted topics will be:

• Advisory/Article about new vulnerability in PHP (with or without exploits) (no simple safe_mode, open_basedir bypass vulnerabilities)
• Advisory/Article about vulnerability in PHP related software (popular 3rd party PHP extensions/patches, like Suhosin or Zend tools)
• Detailed article about a single topic of PHP application security
• Article about a complicated vulnerability in/attack against a widespread PHP application
• Article about a complicated topic of attacking PHP (e.g. explain how to exploit heap overflows in PHP?s heap implementation)
• Article about how to attack encrypted PHP applications
• Release of a new PHP security tools
• Other topics related to PHP (application) security

Of course we will accept multiple submissions by the same person/team and there will most probably also be articles/advisories by ourself. (But of course we cannot win the prizes)

We at SektionEins are already very excited about the event and hope it will be a success and once again improve the security of the PHP ecosystem.

I’ve been doing a lot of work with services and working with them in various ways from PHP. There are a few different ways to do this, PHP has a curl extension which is useful, and if you can add PECL extensions then pecl_http is a better bet but there are a couple of different ways of using it. This post shows all these side-by-side.

POSTing from PHP Curl

This is pretty straightforward once you get your head around the way the PHP curl extension works, combining various flags with setopt() calls. In this example I’ve got a variable $xml which holds the XML I have prepared to send – I’m going to post the contents of that to flickr’s test method.

First we initialised the connection, then we set some options using setopt(). These tell PHP that we are making a post request, and that we are sending some data with it, supplying the data. The CURLOPT_RETURNTRANSFER flag tells curl to give us the output as the return value of curl_exec rather than outputting it. Then we make the call and close the connection – the result is in $response.

POSTing from Pecl_Http

Pecl_Http has two interfaces – one procedural and one object-oriented; we’ll start by looking at the former. This is even simpler than in curl, here’s the same script translated for pecl_http:

This extension has a method to expressly post a request, and it can optionally accept data to go with it, very simple and easy.

POSTing from Pecl_Http: the OO interface

Finally let’s see what the OO verison of the extension looks like. Exactly the same call as both the above examples, but using the alternative interface, means our code looks like this:

This example is quite a bit longer than the previous one, and you might think this indicates that this approach is more complicated. In some senses that is true and its probably overkill for our extremely trivial example. However it is worth mentioning that the pecl_http extension is extremely flexible and powerful, and can handle some cases that the curl extension can’t. So even if it looks more complicated here, it can still be an excellent choice to implement.

In Conclusion

That was a very fast round-up of three ways you could make an arbitrary web service call from PHP – hopefully these examples are clear and will help anyone just starting to implement something along these lines.

A new Gartner report about PHP – PHP: Past, present and Future is mentioned in the last Zend newsletter. Even though I remain somewhat sceptical towards similar reports it is good to see that even Gartner is catching up. What they say actually do have an impact.

"PHP has been a cornerstone technology on the Web for more than a
decade. While its adoption among mainstream IT organizations has been
limited in the past, many corporate application development (AD)
projects are discovering the unique benefits of PHP."

One particular advice is especially interesting for large companies.

"Consider PHP as a supporting technology in a broader portfolio of AD
technologies, where it can provide a specialized toolset for building
Web graphical user interface (GUI) front ends to service-oriented
architecture (SOA) back-end services."

PHP is a fantastic tool for building rich web applications. It?s extensibility makes it versatile and extremely easy to integrate with modern integration solutions as Web Methods, legacy systems or just about any database technology.

To me – this has always been where PHP really shines.

PHP is like a handgun. On its own, it is simply an inanimate tool that has no moral leaning. In the hands of a responsible citizen, it can be used to the benefit of society. But in the hands of someone who is untrained or mentally unstable, it can be used to commit horrible atrocities.
Whenever [...]

About a year ago I wrote about How to get a Singleton right. While nothing has changed my opinion about the Singleton Design Pattern – contrary, I’m even more convinced that it is bad, bad and bad – I still have homework to do. In the comments to this article I was asked about my opinion on the Registry Design Pattern, and I promised it would be worth an own blog entry. Well, I did not anticipate it would take more than a year to write it, but you know, work, and no time, and yada yada yada… so here it is.

When thinking about a Registry one has to consider two points: overall architecture of the application, and implementation of the Registry itself. It’s not that much what you can say about the implementation of a Registry. For PHP, it should just follow one rule to make it testable and to ease testing of classes using the registry: do not make it a Singleton. (You might have guessed that already.) PHP offers the possibility to implement the Registry as a pure static class, where data within the Registry can be stored within a static class variable, and setters as well as getters can also be static methods. There is no value in making it a Singleton, it just more stuff to type where the result is the same: global state. So if you implement it as pure static, the Registry in itself is neither bad or good.

Speaking of global state, it should be common sense by now that global state is a bad idea, at least if this global does not mean the root of the application itself, which leads us to the overall architecture of the application. How is this related to the Registry Design Pattern? The Registry is intended to allow access to configuration data, objects etc. which you don’t want to pass around in your application but require them in different parts (or layers) of your applications. If you have such a need from my point of view this means the application is not fully based on the Dependency Injection principle, it does not separate object creation and business logic as much as it should. If the application is completely based on Dependency Injection, there is no need for a Registry any more.

Did I just say that there is no need for a Registry any more? Well, two exceptions. First, unfortunately in PHP there might be cases where you can not influence the creation of an object instance, and if you want to pass data or other objects to such an instance, you have to take cumbersome actions to pass those. Creation of user land stream wrapper instances is such an example, as those instances are created by PHP itself and there is no possibility to intercept this. Here a Registry might be of help, but it stays what it is: a workaround for a flaw in PHP.

The other exception is the case of using a Dependency Injection framework. You do not need a Registry here – your DI framework already has something like this. It just not called Registry, but it is it’s mechanism where you bind data or objects for example in the case of Stubbles or Google Guice, and in Symfony it is called Service Container. (Please note that this is just a quick thought I had in the last days, I might be wrong on this.)

To conclude, the Registry itself is neither useful or harmful. The more important question is how strong you apply the Dependency Injection principle in your application.

London, UK