Re: Security Issues - a bit of my experience

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.