Re: Security Issues - a bit of my experience

On Mon, 30 Jul 2001, Ramsi Sras wrote: Hey, idiot. you can just send a message to php-dev-unsubscribe@lists.php.net, stop spamming my mailbox, or else you'll be subscribed to alot more mailing lists than you ever wanted. -Sterling > 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 >