Vendors

PHP security guru Stefan Esser recently posted on some of the changes and important security issues that are likely to have significant effects for the everyday PHP coder (and user) with the release of the upcoming PHP 5.3.

Probably the simplest and most effective change that will come with PHP 5.3 is a modification to the way that $_REQUEST superglobal variables are handled. After several years of known vulnerability, it seems that the PHP developers are finally addressing one of the most risky elements of the scripting language.

For those who are unaware, the $_REQUEST superglobal variable in PHP is able to be called from anywhere in any PHP script, can not be overwritten/replaced by a user variable of the same name (though the contents can be changed) and is an associative array with the values passed via GET, POST and via cookie to the particular script ($_GET, $_POST, $_COOKIE PHP superglobals).

It took several years for the idea of disabling register_globals in the php.ini to be a default practice, and it is due to be removed from PHP 6.0 (if register_globals was enabled, any local variable could be overwritten by an equivalently named element of a superglobal array - $_GET['foo'] would overwrite $foo), but it still persists in odd corners of the Internet.

The difficulties associated with stamping out the register_globals directive are sure to be have been in the minds of the language developers when deciding to change the handling of $_REQUEST. As described by Esser, the primary change to $_REQUEST is a means to control what superglobals are looked at to form $_REQUEST, and in which order, without actually destroying or modifying the original superglobals. This means that $_REQUEST could be used to only monitor $_GET and $_POST submitted variables and ignore $_COOKIE values, or any other combination of the three.

Why not just get rid of $_REQUEST all-together, since $_GET, $_POST, and $_COOKIE already exist? Too many applications built in PHP are likely to use $_REQUEST in some form to enable a complete cutout of the superglobal. $_REQUEST does make the developer's life a little easier as they can accept user input from $_GET or $_POST without discrimination (though it is poor form to do so), but there are significant risks with allowing the user to arbitrarily overwrite values in either $_GET or $_POST.

Developing with a secure mindset means that all user-supplied data is considered potentially malicious, so it shouldn't really be a problem at the end of the day but using the relevant $_GET or $_POST superglobal vice $_REQUEST does make for better and more readable code.

Should developers continue to have access to risky functions, even when there are safer alternatives present in the core language? Some would argue that by not having the temptation in the first place, that the resultant software developed will be more secure by default, and that if developers really need access to a similar capability, they can code it themselves. Alternatively it could be argued that developers should be aware of their language of choice's limitations before attempting to code in it. Site after poorly coded site, project after poorly developed project, and sites such as the Daily WTF show that this is an extremely optimistic view to take, and one that is not borne out by reality.

In the future it is possible that $_REQUEST will go away completely, and developers should begin looking through their code to see what they can start doing now to make their code ready for future PHP versions, with the side benefit of making it more secure.

Slideshows

Google and Microsoft tackle triple value play at Synnex Alliance 2018

This Synnex Alliance roadshow, in association with Google and Microsoft, started with the end-user and worked back to define the notion of value, outlining the lucrative partner opportunities ahead in 2018.

Changing names: the top company rebrands hitting the channel

The past year has seen a flurry of acquisitions, sales, consolidations and business transformations in the local tech sector; ARN takes a look at the company name changes and rebrands across the Australian channel that have resulted from all this activity.

Upcoming tech talent share insights at Emerging Leaders 2018

The channel came together for the third running of the ARN Emerging Leaders Forum in Australia, created to provide a program that identifies, educates and showcases the upcoming talent of the ICT industry.

Copyright 2018 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.