Thanks for the "cool" response Zeev.. I was a little agitated when I wrote
that letter, glad you didn't take it the wrong way.
Again, my position is very simple. I agree that what you are suggesting
would greatly reduce the exploits of the language. Just concerned about the
cost, and if the benefit/cost ratio is in the right ballpark. I think it
might be too much of a cost, for not enough benefit.
I personally feel that these issues up to the programmer, (hence the
difference of opinion). This change will break many of my scripts, some of
which can take variables from Get, Post, or Cookies. I'm not looking
forward to writing the logic to *fix* all of these, when my scripts are
secure as it stands now.
You asked if I examined my scripts, could they be caused to behave
differently if someone knew the source?
Differently - sometimes
Dangerously - Never
And my apps are not exactly hit counters either. I'm actually working on a
very large project that I'm going to tell you all about one day soon, when
its done ;)
-Brian T
-----Original Message-----
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: July 27, 2001 10:06 AM
To: Brian Tanner
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] Security Issues
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]
