At 10:19 27/07/2001, Brian Tanner wrote:
>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.
I don't know if that's just one guy or a group of people, but that one guy
found exploitable bugs in pretty much any big PHP app he
researched. Instead of ignoring his findings and saying he's just one guy,
it's best to read the advisory and understand that he's really right about
his assessment, that register_globals is the mother of a huge number of
security flaws in PHP applications.
>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.
That's simply not true, and it should be clear that it's not
true. Teaching people to use $_GET["foo"] is not more difficult than
teaching them to use $foo. It's also more explicit and clear to read. If
we were in front of a blank design board right now, it wouldn't have even
be a question. The new method is equally clear, and has some advantages
(the only disadvantage being a few more keystrokes, but that's not a big
deal). The only reason we're having this debate is due to downwards
compatibility.
>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.
Take a look at your apps, take a close look, and see if they're vulnerable
to such attacks. Your apps may not be doing any 'dangerous' stuff, but
try to see if a remote user, knowing the source code of the script, could
cause your apps to behave differently with the right input. From my
experience, many, if not most of the scripts fall into this category. If
it's 0.1% of the population making mistakes, it's one thing. If it's 20%
or 50%, it means that the language is at flaw. Even if you disagree that
the language is at flaw and 'people should be taught how to drive more
safely', there's no doubt that decreasing the chances of them making an
accident very considerably is a good thing. As I told Peter, we're not
talking about liability here, or who's to blame. We're trying to figure
out the best way to convey PHP to people, and make them create good PHP
applications. Right now, PHP encourages them to write bad apps, which is a
bad thing, and gives PHP bad reputation.
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]
