Re: Security Issues

On Fri, 27 Jul 2001, Zeev Suraski wrote: > (a) How about just setting register_globals to on? We're not talking about > taking this option away, for now, just turn it off by default. > (b) As I said, if someone wants to use a gun to shoot himself in the head, > he's welcome to do so. The least we could do is hand him the gun safely > pointed in the other direction, and not point it to his brain. We know that tricks and complications don't make anything more secure - quite the contrary, they make the applications more bug-prone. We also know that good programming practices and routines help avoid bugs. Alone, they won't help, but a person who is adviced or even enforced to apply those practices will usually wonder: "huh, why shouldn't I use tempnam or gets? Hmm, maybe I'll read the manual page...". Indirectly, this also leads to changes in attitude as the programmer starts to realize that the threats he or she is being warned of are real and not mere paranoia of people encrypting their swap. The question here is whether or not register_globals is a trick or a way to advise people of better practices. Would anyone like to show me the design that gets innecessarily ('innecessary' meaning 'if the application wasn't well designed in the first place, it's obvious it should be changed') complicated when you enforce E_NOTICE and register_globals? // Everyone's emphasizing documentation on security concerns. What would be the first things I'd like to see (or do) tre he possible security implications for function calls or language structures in the reference manual, next to their corresponding references. See, for example, the bugs section of one implementation of the manual page for mktemp(3): http://www.openbsd.org/cgi-bin/man.cgi?query=mktemp&sektion=3 Yes, sure it would be nice if there was a guide to secure programming in PHP. Oh, but wait... I think there are some; but people don't necessarily read them. They think that security issues don't concern them. -- <----------------------------------------------------------------------> Heikki Korpela -- heko@iki.fi -- http://iki.fi/heko/