Re: Security Issues - a bit of my experience

UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!!UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!!UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!!UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!!UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!!UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!! Zeev Suraski schrieb: > At 21:34 29/07/2001, Stephen van Egmond wrote: > >Zeev Suraski (zeev@zend.com) wrote: > > > - register_globals=on leads to insecure code, which was demonstrated time > > > and time again in the past. > > > - Once it's off, we're going to provide methods of accessing variables > > > which are just as easy, and quite easier in case you access them from > > > functions. Having form variables register as global variables is not the > > > 11th commandment, and it's kind of odd to see people treat it as such. > > > >It is quite the handy feature, and it will be a bummer to see it go. > > It's not going. It's just being turned off by default and flagged as "use > only if you REALLY know what you're doing" feature, and don't really care > about portability (the only way to write portable PHP apps is to assume > register_globals is off, that's been true for a while now). > > > > - E_NOTICE is a runtime issue, one which you would have to check under all > > > possible paths in your logic. That's why leaving security stuff to > > runtime > > > is always never a good idea. Setting register_globals to off gives you > > > development-time security. > > > >I must point out that if we're referring to existing code bases, > >E_NOTICE and register_globals=off require as much work: all code paths > >have to be exercised to catch all the old-style idioms. > > I disagree. For E_NOTICE=off, you have to go through all of the possible > logical paths. For register_globals=off, you only have to know your input > variables, and a search&replace would do. It's true that in some apps, > where you have no idea or don't remember what the input variables are, it > would take some time to figure out what the input vars are, but it's still > much easier than going through all of the possible logical paths. > > >I was trying to step back a bit and identify some of the patterns in > >the attacks identified in the paper. One extremely popular pattern was > >spoofing variables by overwriting them: GET variables overwriting > >POST, usually, and I suggested that some SAPI stunt be pulled to catch > >that. > > > >Although this would improve things, it bears noting that: > > > >- it deprecates a valid (on Apache) idiom which, at least, Rasmus uses > >- this only makes it harder to spoof variables, not impossible. > > But at least that's something. > > > >Whatever. The idea hasn't caught on. I recognize it probably wasn't > >worthy. > > Protecting POST vars from GET has no serious security viability, even > though as I said a few days ago, in practice, a hell of a lot more people > know how to spoof GET vars than those who know how to spoof POST or cookie > vars. I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give > you the best of all worlds, as it would really lead you to use the right > variable for the job. > > Zeev > > -- > 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