Re: Security Issues - a bit of my experience

UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!! Stephen van Egmond schrieb: > Rasmus Lerdorf (rasmus@php.net) wrote: > > Think about whether in each of these cases it would have happened if the > > developers of the app had developed with E_NOTICE on. In a high number of > > these cases it probably wouldn't. And if this number is close to 100%, > > then it would point to the fact that there is another less destructive > > solution here. > > > > This is why I want to go through and investigate existing PHP code and > > have a look. > > I'm a user of PHP, who would describe himself as approaching "expert" > in my knowledge. > > I took a suggestion from earlier in this thread, and turned off > E_NOTICE. An excellent idea. I found a few holes in some of my code, > which I was glad to repair, and grateful to the language for pointing > out to me. > > The suggestion to turn off register_globals by default is an extremely > bad one. It would make using PHP nothing short of a pain in the ass, > break vast amounts of code, and not improve a whole lot. I _LIKE_ that > I can GET or POST to a page, and the variables will still come from the > right place. > > While considering the security angle, it's important to notice that > there is a tradeoff between a secure system and a functional system, > and that for some people, security just doesn't rate: either the > function (e.g. register_globals) is too valuable, or the downside of a > security failure is just not all that great. A lot of people prefer > function over security, and would find it an unwelcome arrogance if PHP > forced them to twiddle some settings to get it back. > > Finally, a small note from my PHP programming experiences: > > In order to code with E_ALL, idioms like this: > if ($x) > > will produce warnings if $x is not set. If you don't want the > warnings, you have to replace it with: > > if (isset($x) && $x) { > } > > "if it's set and it's true"...? ugh. > > One is then tempted to look for replacement functions in the > library, and immediately hits upon empty. > > if (!$empty) > > But as can be seen from the table at > http://bang.dhs.org/~svanegmond/logictest.php , empty() > returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics > of empty() are a good replacement for the warning-generating cast to > boolean. > > This tends to make E_NOTIFY more trouble than it's worth... which is > why people (including the Debian package maintainer) keep it disabled. > > Thus I recommend that empty() be fixed to return false for boolean > values. Failing that, that a non-warning-generating logical > equivalent of cast-to-boolean be provided. > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net