Chris
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.
Debbie
----- Original Message -----
From: "Chris Shiflett" <[EMAIL PROTECTED]>
To: "debbie_dyer" <[EMAIL PROTECTED]>
Cc: <[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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
