On Mon, 30 Jul 2001, Ramsi Sras wrote:
Hey, idiot. you can just send a message to
[EMAIL PROTECTED], 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 ([EMAIL PROTECTED]) 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
