Regarding Rasmus' quote I'm afraid I'm going to have to disagree with him to a point.

If register_globals is off then there is no exploit and the script most likely will not function as expected forcing the programmer into a bit of debugging.

It may well have but that is no bad thing. It forces newbie programmers into a little research into why their script does not work and makes them learn about variable scope and how to properly access the php global arrays (something they should be doing anyway).

I agree totally. You should do as Rasmus says and increase the level of error reporting. At the top of your scripts add this line
That will tell you when you are using variables that you have not initialized. You SHOULD initialize all variables to a default value before using them.

Thats basically what Rasmus is saying. If you up the level of error reporting to show uninitialized variables and then initialize them then there is no difference in how your application will function whether register_globals is on or off.

But, and its a big but, the default error_reporting setting in php does NOT report uninitialized variables and newbie programmers coding on a server with register_globals on can code away till their hearts content blissfully unaware of the glaring security holes in their application.

The reason it is now off by default is to save newbies from themselves.

I'll leave my thoughts on register_globals at that before I go writing a tutorial on variable scope.

Onto Magic quotes.
magic_quotes_runtime when on will escape (addslashes()) to all data returned from an external source (database data, reading in a text file etc).
magic_quotes_gpc when on will escape (addslashes()) to all incoming $_POST, $_GET and $_COOKIE data.

Again these are an example of trying to preempt the programmer and do something that the php group thought was helpful. It all sounds good but what if you move your application to another server and the magic_quotes_gpc is set to off? You then have to manually addslashes() to data (if you want it escaped of course). I swear a few microsoft programmers must have sneaked onto the php group :)

So what to do about it? its down to your programming style, do you find them helpful or a hindrance as I do?

I always turn off magic_quotes_runtime by adding this at the top of my scripts
I then check to see whether magic_quotes_gpc is on with get_magic_quotes_gpc(); and if it is I traverse the $_POST, $_GET and $_COOKIE arrays and stripslashes() on them.

I prefer to get data to my scripts exactly as the user typed it so as I can run my own sanitization routines without wondering what a particular php setting did to it.

Another reason I dont let php do any escaping of input is running string comparisons on input is thrown out the window if php alters the input. Also if you are sending form data back to the browser you have to go stripping slashes on all the data.

When it comes to escaping data before inserting into a database well MySQL is my db of choice and it has its own function mysql_real_escape_string() that prepares data before inserting it which takes into account the actual character set in use by the database (something the php functions do not).

Magic quoutes is all down to what you prefer, if you like them then be sure to check if magic_quotes_gpc is on or off and addslashes to the arrays to make your code portable.


Use full error reporting, initialize all variables, trust NOTHING input by a user, validate everything (then check it again).