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]

Reply via email to