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:
$logged_in=0;
if (is_valid($password))
{
$logged_in=1;
}
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.
Chris
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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
