Your description of register_globals is good, except that the "security 
risk" is a matter of opinion. I would argue that register_globals only 
presents a security risk to inexperienced developers.

The client can submit any data to your application regardless of any 
configuration (and even regardless of language used). PHP's 
register_globals provides a convenient mechanism for receiving data from 
the client. In general, there are two types of data:

1. Data from the client
2. Data residing on the server

Code that allows data from the client to overwrite data residing on the 
server is poorly written code, and this is the scenario that creates 
this misconception of register_globals being a security risk. Data 
residing on the server can be information in a database, session data, 
etc. It is quite trivial to ensure that this data is overwritten. When a 
script begins execution, the client can no longer submit data. It is 
finished and can do no more so to speak. This makes things very easy. 
Thus, consider this:


if (is_valid($password))

Guess what? The client cannot make $logged_in = 1 unless the password 
they provide passes the is_valid() function (a function you create to 
validate a password - just a hypothetical example). There is no way a 
client can submit any data in between these statements. The problem is 
when people fail to set $logged_in to 0 initially, so that a failed 
password simply avoids the if statement but doesn't explicitly set 
$logged_in to 0. This is poor programming.

For session data, try to override data that is initialized with 
session_register() and see if it works. What you will find is that 
whatever the client sends is overwritten by the data in the session, so 
this scenario is also easy to avoid.

My point is that most risks can be avoided by understanding how the Web 
operates and programming to the transactional nature of it. It is so 
easy to make sure that the client cannot overwrite server data. I think 
register_globals is far too often blamed for misunderstandings.


debbie_dyer wrote:

>If it is on - its a security risk because anyone can change the
>value of the data in your script by passing values in thru the URL.

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to