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 <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]
--
Zeev Suraski <[EMAIL PROTECTED]>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
--
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]
