> I tend to agree with the advisory, in the sense that register_globals=on
> encourages insecure code, and it would in fact help to disable it by
> default.  It's true that some (many) people don't understand that they
> shouldn't 'trust' any data coming from POST or cookies anymore than they
> should trust GET (well, in practice - slightly more, as it takes slightly
> more advanced users to work around POST or cookies, than it does to add GET
> variables to the URL).  However, *lots* of pieces of code, probably even
> most of them, are vulnerable to logic bugs because of register_globals set
> to on, bugs that would have otherwise not exist.  Bugs which occur due to
> misunderstanding the 'reliability' of the form data sources are (much) more
> rare, and usually, if not always, involve basic misunderstanding of the Web
> environment.  Security issues that are a result of register_globals=on
> often occur even when the user is knowledgeable, and tries to avoid
> security bugs.  The WTF factor there is pretty high.

But you don't acknowledge here that turning on E_NOTICE by default would
effectively eliminate this coding mistake.

> >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.

> 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.

> >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


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]

Reply via email to