Generally I agree, except I don't think we should go as far as changing the 
theme of PHP.  Putting form variables into a different space would be the 
simplest and equally secure way to do the trick.

At 08:32 26/07/2001, [EMAIL PROTECTED] wrote:
>Hi Zeev!
>On Thu, 26 Jul 2001, Zeev Suraski wrote:
> > At 02:18 26/07/2001, Ron Chmara wrote:
> > >>   If most of the PHP apps out there are or were vulnerable to
> > >> register_globals=on attacks, we can't (shouldn't) blame the whole 
> world,
> > >> but fix the language instead.
> > >
> > >I'd suggest fixing the code religion instead, but changing faiths is 
> hard.
> > >:-) If they aren't checking their vars before processing, no language
> > >would fix it, would it?
> >
> > Most would, actually.  Pretty much any language which requires you to
> > declare variables, or, that doesn't allow external sources to declare
> > variables, does not have this problem.  PHP is quite unique in that sense,
> > which is why I agree that the language is at fault.  Of course, declaring
> > and not initializing your variable is still a programming error, but it's
> > much less severe and much less prone to exploits than this problem.
> >
>May I jump in? :)
>As I see it, the security issue is "Untrusted data coming from the user",
>which collects under the "request" term.
>What is overwritten? Server vars or user vars, and that's because there's no
>hard separation between them in the "register globals on" case (all in the
>same pot).
>So why wouldn't PHP propose a Reques-Response paradigm like ASP,JSP or Zope,
>before we have namespaces and such?
>If I say $Request->getAttribute('geez') I am damn sure it comes from the user
>and I consider the value inherently suspicious (i.e. don't just stuck it in
>a mysql_query() string w/o testing.)
>This can be done at PHP level or language level (where other security tests
>can be addressed.)
>The best teaching the pear/php devs can give to the user in the security issue
>is to promote best programming practices, and IMO this is one of them;
>otherwise they'll have to gulp bitter advisories about this and that popular
>PHP application having an ungly bug (see phpMyAdmin, IMP, Phorum, etc.)
>my 2c
>-- teodor
>PHP Development Mailing List <>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd.

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to