Re: Security Issues
| From: | Ron Chmara | Date: | Thu, 26 Jul 2001 09:18:41 +0000 |
| Subject: | Re: Security Issues | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-61041@lists.php.net to get a copy of this message | ||
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 ron@opus1.com, 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.