On Wednesday, July 25, 2001, at 06:32 PM, Zeev Suraski wrote:
> Guys, look back at the advisory. Apps written by *GOOD* PHP
> coders who *ARE* aware of security issues were prone to
> register_globals=on attacks.
telnetd on almost all of *BSD is a big hole right now.
Good coders make mistakes.
> As the guy said in the advisory, it's arguable whether it's the
> language's responsibility to guide you to write a secure app,
> or whether it's the coder's responsibility. He says, and I
> agree with him, that if the language 'encourages' you to write
> insecure apps, by providing and streamlining insecure ways of
> implementing functionality, the language is at fault.
I agree... somewhat. The manual didn't even have a dedicated
security section until recently, and we are faced with hobbling
PHP, and making it unusable for low level tasks (to insulate
users from ever shooting themselves in the foot)
or:
creating many new functions that can not do things like write
files, read files, open sockets, or other low level tasks (the
javascript approach)
or:
failing to execute a PHP script which had warnings, errors, or
otherwise had "problems"
or:
slowly migrating code which does bad things into good things.
If a user thinks of PHP in the same terms as javascript, PHP is
evil, as it can do all sorts of things that javascript can't.
That's a good thing. PHP. IMNSHO, is not just a web page
counter, or popup, or pretty click. It is a full fledged
language, that can do as much damage as giving the web surfer a
shell. Coders need to treat it as such.
> If most of the PHP apps out there are or were vulnerable to
> register_globals=on attacks, we can't (shouldn't) blame the
> whole world, but fix the language instead.
I'd suggest fixing the code religion instead, but changing
faiths is hard. :-) If they aren't checking their vars before
processing, no language would fix it, would it?
--2D426F70|759328624|00101101010000100110111101110000
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those
of myself,
my employers, or any of the other little voices in my head.
--
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]
