Yes, anything passed in the URL can be obviously altered which is why you should always check the data you receive (validation). The real issue with using register globals is that it is a very easy way for unscrupulous people to change your code. Never rely on receiving what you expect...check for it and discard anything that doesn't fit.

The elimination of register global variables reduces the chance of malicious users "leaking in" variables that have nasty content. Now you have to explicitly import these variables with $_GET, $_POST, or $_REQUEST, which cuts the chances that you've forgotten to give valid default values before importing the actual value (if any) with $_REQUEST, etc. Of course, you still should validate a variable's data before making use of it, to prevent injection attacks and the like. It doesn't matter how a variable used in your code arrived (explicitly via $_REQUEST, or implicitly via register global variables) if it contains bogus content. Turning off register globals simply forces you to take an extra step and be a little more careful in your code design, so that you can't overlook setting your variables along any possible code path.

We recently got a Job Portal Package and we uploaded in the server some of the links where not working for applying for the job and so on and finally we asked our developer guys who sold this Job Portal Package he said you must ask the Hosting guys to change the register_global to ON as its OFF. Then we asked the Hosting Guys they said they cannot do it as it will be easy for the hackers to hack the server.
Now we are struck both the sides; As the developer is not ready to change his coding to suit the Server and most of his codings are done with ioncube to encrypt the files. We are totally struck.

Is there any way we can solve this problem by uploading some files in the document root to change this register_global ON or to make the codings work.

Hope you can help us

Hi warmmelody,

MrPhil is correct. This is not something that we can change server wide but you can adjust it to ON or OFF as needed for your scripts using a custom php.ini file. This link may be helpful:

http://wiki.lunarpages.com/PHP_and_Register_Global_Variables

No, you (and maybe Jacob, I can't quite tell what he's getting at) are referring to a different kind of global variable. Those are things like $GLOBALS, $_SESSION, and $_SERVER. This discussion is about "Register Global Variables", which are a different color of horse. These are a means to pass user data (via form or URL) from one page to another. The old method simply referred to them by normal name on the receiving page, but this is a security risk, as variables can be maliciously leaked in. The new method puts in an extra step, so that only those globals explicitly listed ($_REQUEST['name'], etc.) will be honored. Calling them "User Global Variables" or something like that would have been better, but that's water under the bridge.

"Superglobals" vs. "Globals" is also a distinction, where superglobals don't need to be listed in a "globals" statement.