Is all of this springing from that security advisory that was published a
short while ago?
I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).
Also, wasn't that advisory just written by some guy? Its not like W3C is
writing a web security standards document and made an example out of PHP or
something, its just the security suggestions/opinions of some guy.
Seems like a whole lot of trouble (breaking thousands of scripts) -- just to
appease some document by some guy.
Also, about this whole "car with no brakes" or "gun aimed at the head"
business. I like the car analogy... and the register_globals="off".
See.. turning register_globals off is like adding a huge brake, and then
hiding the accelerator. For beginner drivers, or existing drivers that are
not up on current events, it will be very hard to get going.
I'd say that leaving register_globals on is *exactly* like a regular car.
Its dangerous, hell yeah. However, as long as you learn how to use it in an
enclosed environment, and practice the safety techniques -- you are not too
much of a danger to others when you get onto the highway.
Same concept applies... if you take a beginner and put them on an enterprise
server writing code that manipulates a DNS file or does updates and deletes
to a crucial database, you are asking for trouble.
Thats why people write simple, inconsequential application as they are
*learning*, and after that have some experience, they should write things
where they can actually hurt someone.
Anyway, thats my .02. I'm done talking about this issue... its a difference
of opinion, which is generally very hard to resolve -- and no amount of
logical dicussion can change the mind of either group.
-Brian T
-----Original Message-----
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: July 25, 2001 6:29 PM
To: Rasmus Lerdorf
Cc: Andy; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Security Issues
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]
--
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]
