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
>with.
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.
Zeev
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
