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]
