At 07:31 25/07/2001, Rasmus Lerdorf wrote:
>Because not everyone agrees that this is actually "highly recommended".
>Most third-party PHP code you may want to run will not work very well with
>register_globals off. And turning register_globals off isn't actually as
>helpful from a security perspective as many people seem to think.
>
>The basic thing it would help would be in cases like this:
>
> <?
> if($user=='rasmus') {
> $ok = true;
> }
>
> if($ok) {
> ... secure code ...
> }
> ?>
>
>Here if someone injected ?ok=1 in the URL then the secure code part would
>be run regardless of the $user setting. Obviously the fix here is to make
>sure that $ok is initialized to false at the top of the script. But since
>many people forget to do that, turning off register_globals "fixes" the
>problem.
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.
>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.
>Many people also seem to think that it is somehow more secure if you know
>exactly where data is coming from. So that if you use
>$HTTP_POST_VARS['var'] then somehow $var is not spoofable because if you
>put ?var=foo in the URL it won't affect anything. But injecting variables
>into POST or Cookie data is trivial so I don't see this argument holding
>much water either.
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.
>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.
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]
