At 21:14 25/07/2001, Rasmus Lerdorf wrote:
>But you don't acknowledge here that turning on E_NOTICE by default would
>effectively eliminate this coding mistake.

No, because it won't.  As I said, you can cleanly implement this with 
empty(), and there'd be no E_NOTICE's or anything.

> > >The change I would rather see in php.ini would be to have the default
> > >error_level be set to E_ALL because then the above script would generate a
> > >warning complaining about the fact that $ok was not initialized.  Since
> > >PHP can determine when variables are not initialized the case for
> > >turning register_globals off in this example is rather weak.
> >
> > PHP does not require or even encourage initialization of variables -
> > setting $ok to 1, and then checking it with empty() is considered 'clean'
> > code, but it'd be equally insecure.
>Huh?  Please show a code example here.

Just replace your if ($ok) with if (!empty($ok)), and you have a perfect 
exploitable code that produces no warnings.

> > As I said, it's easy, but it is considerably less easy than it is to add
> > GET variables.  Let alone the fact that we're also dealing with SERVER and
> > ENV vars, which cannot be injected at all.  How about people who check
> > server variables, such as HTTPS, using isset()?  register_globals *is* 
> evil.
>We are talking about default settings here.  You cannot spoof this script
>using the current default:
><? echo $REMOTE_ADDR ?>
>You can stick all the ?REMOTE_ADDR=foo you want in the URL and the server
>var will always overwrite it in the default config due to the default
>variables_order setting.

Right, but I gave a more specific example - HTTPS, which doesn't always 
exist, and its very existence implies something.  Not all variables are 
exploitable, perhaps even most aren't, but many are.

> > >And the case for leaving register_globals on is that it is a whole lot
> > >easier for people to figure out how to get started with PHP when the data
> > >is just there and you don't have to do any strange array tricks to get at
> > >your data.
> >
> > I don't think that this arguments holds much water, as register_globals is
> > the mother of many many security bugs, found in the most popular PHP apps
> > out there.  We need to find a way to access form variables easily, but
> > without encouraging insecure coding, the way we do now.
>I disagree.  Please show examples of this mother of all security bugs
>here.  Examples of this not caught by E_NOTICE are difficult to come up

They're trivial to come up with;  Pretty much any good code (E_NOTICE free) 
that doesn't take into account the fact that variables can pop out of 
nowhere into your global namespace is exploitable.


PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to