Re: Not Displaying From Vars??

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" <shiflett@php.net> To: "debbie_dyer" <debbie_dyer@surfanytime.co.uk> Cc: <php-general@lists.php.net> 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. > > >