Time to Make Your Code Compatible with PHP 6 · English

phpINSIDE magazine is calling on developers to make their code compatible with PHP6.

The authors of the “Making the web” blog suggest that we start writing code with PHP6’s requirements in mind right now.

At a minimum, this means:

forgetting about register_globals
stopping the use of magic_quotes
not using the long names for global arrays (example: $HTTP_POST_VARS)
starting to use preg instead of ereg for regular expressions
and not creating objects by reference

Yes, PHP6 really is just around the corner, and now we’ll try to adapt our code to PHP6’s requirements.

Using Global Variables (Register_Globals)

Probably the most controversial moment in PHP’s development was changing the default value of the register_globals option from ON to OFF in version » 4.2.0. Most users trusted the developers without even knowing what this option was or how it affected PHP’s behavior. This documentation page is intended to show how this setting relates to security issues in application development. It is important to understand that this option does not, in itself, affect security; the threat comes from incorrect use of the capabilities it provides. When register_globals is set to ON, various variables will be initialized before your code runs—for example, variables submitted through a form. Also, given that PHP does not require variables to be initialized, it is very easy to write potentially dangerous code. This was a very controversial decision, but the PHP developer community decided to change this directive’s default value to OFF. Otherwise, when writing code, developers could not say with confidence where a particular variable came from or how trustworthy it was. Before this change, variables defined by the developer within the script and external data supplied by the user could get mixed together.

More details: http://ru2.php.net/register_globals

How do you change register_globals from “ON” to “OFF”?

Add this to .htaccess (Apache’s supplementary configuration file)


php_flag register_globals off

Once you have done this, data entered by the user will not automatically be turned into variables and will instead be stored in the global variables $_GET, $_POST, etc. For example: what used to be $page becomes $_GET[‘page’], or what used to be $login becomes $_POST[’login’].

Magic Quotes (magic_quotes)

For many reasons. The most obvious one is a matter of logic. “Magic quotes” add slashes not where they are needed—when building a query—but before the data even reaches the script! Yet the data will not necessarily be inserted into a query afterward. It might need to be displayed to the user, in which case the slashes will only get in the way. What’s more, the added slashes will, for example, prevent us from correctly checking the length of an entered string. Besides, it is not just data coming from the user that we need to escape with slashes, but absolutely any data inserted into a query—this obvious fact has never even occurred to many people! The list could go on, but there is only one conclusion: slashes should not be added automatically and indiscriminately before the script starts running, but only where they are actually needed—when building a query. There is another reason, too: when using Unicode encoding, which is becoming increasingly popular and will eventually dominate the web, magic quotes can simply corrupt the text by mistaking part of a multibyte string for a special character. Among the reasons not to rely on “magic quotes,” there is one more. A very unlikely one, but still. There are actually not two directives associated with “magic quotes,” but three. The third is magic_quotes_sybase. Not only does it add a quote instead of a slash, it also overrides magic_quotes_gpc. If, by some miracle, both directives are set to ‘on’, the latter will not work! In other words, if we rely on “magic quotes” in this case, we will get all the delights of incorrectly constructed queries. In general, purely in theory, we should account for the presence of this directive, since it also brings a surprise such as… changing the behavior of the addslashes and stripslashes functions! If magic_quotes_sybase = on, these functions start adding and removing a single quote, respectively, instead of a slash.

More details: http://www.php.net/manual/ru/ini.core.php and http://ru.wikipedia.org/wiki/Htaccess

How Do You Disable It?

Add this to .htaccess (Apache’s supplementary configuration file)


php_flag magic_quotes_gpc 0
php_flag magic_quotes_runtime 0
php_flag magic_quotes_sybase 0

For MySQL database queries, use mysql_real_escape_string().

Example:

Remember that you can only use it after establishing a database connection.

This function does much more than the outdated addslashes and mysql_escape_string. First, it makes MySQL logs easier to maintain and read by replacing, for example, a newline character with “n” and certain other characters with escape sequences. Second, and most importantly, it works correctly with multibyte encodings, taking the current MySQL encoding into account and thus avoiding corruption of Unicode-encoded text.

Here’s another example:

More details about “Magic Quotes” on phpfaq.ru

<span style="color:#BCBCBC;">Завтра постараюсь рассказать почему не следует использовать длинные имена глобальных массивов такие как: "$HTTP_POST_VARS", а также почему  в регулярных выражениях надо начинать использовать preg вместо ereg и не инициировать создание объекта по ссылке.</span>