Yes you are right in what you say but:-

"I would argue that register_globals only presents a security risk to
inexperienced developers."

And how many of these are putting code on the net? - Thousands.

Also, all programmers (even the most experienced) are only human and prone
to error and in my opinion anything that makes it easy to write bad code
cannot be good.


----- Original Message -----
From: "Chris Shiflett" <[EMAIL PROTECTED]>
To: "debbie_dyer" <[EMAIL PROTECTED]>
Sent: Sunday, September 29, 2002 8:21 PM
Subject: Re: [PHP] Not Displaying From Vars??

> 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 (
To unsubscribe, visit:

Reply via email to