Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43993
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.222.185 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=V7idCvuqN9/XEImQs8pTVXWJupbvh7rxEcnWa8A5e0Xj4n3MQU0NqU/d9TfEbOjU0c
         WjIm6DBC8SLLTogwUIwNRLCkoM/nsStnnC4CRZCKesavESl08Y5cs4ycUJtT6CvLRQHA
         KJYo/y7rMawnSmxhwKbq4gCGJ0iC0Fni+XE4s=
MIME-Version: 1.0
In-Reply-To: <C74C4F67-7603-4A6F-82D0-AF3D10665AD1@pooteeweet.org>
References: <bd9320b30905141018q1ebeb994t9676d4d5085a0d6b@mail.gmail.com>
	 <4A0C9516.8060808@gmail.com>
	 <bd9320b30905141733l424179eak67bd287fc134a74d@mail.gmail.com>
	 <4A0D2648.3050802@lerdorf.com>
	 <C74C4F67-7603-4A6F-82D0-AF3D10665AD1@pooteeweet.org>
Date: Fri, 15 May 2009 10:14:38 -0700
Message-ID: <bd9320b30905151014j27b76067of8507c81e125abac@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>, Lukas Kahwe Smith <mls@pooteeweet.org>
Cc: PHP Development <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Why does $_REQUEST exist?
From: mike503@gmail.com (Michael Shadle)

On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith <mls@pooteeweet.org> wro=
te:

>> The more stuff like this we remove, the harder it becomes for people to
>> quickly move to newer, faster and more secure versions of PHP. =C2=A0Tha=
t
>> causes way more frustration for everyone than a few "ugly" legacy
>> features. =C2=A0If there is a decent technical reason, performance or
>> security, then we need to take a hard look at it. =C2=A0In this case, th=
e
>> thing we should be looking at isn't whether we should remove $_REQUEST
>> but whether we should remove cookie data from it. =C2=A0Many configurati=
ons
>> already do that, including all of my own, and there is a strong valid
>> security reason for not including cookies in $_REQUEST. =C2=A0Most peopl=
e use
>> $_REQUEST to mean GET or POST, not realizing that it could also contain
>> cookies and as such bad guys could potentially do some cookie injection
>> tricks and break naive applications.

But since there is going to be a dramatic change here anyway, this is
the perfect time to do it. To me adding namespaces is a lot more scary
and will lead to a lot of confusing code...

P.S. It looks like you'll be speaking at OSBridge in Portland in a
month or so. If I attend I look forward to meeting you and thanking
you for PHP :)

> Its already fixed in 5.3. There is a new ini option that defines what sho=
uld
> go into $_REQUEST. See the following blog post for details:
> http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-f=
orgerieshijacking/
>
> Also a lot of work was put into restructuring the php.ini files we ship w=
ith
> PHP.

This is a good step I think; will it be possible to allow it to be
empty and have $_REQUEST not exist or even be initialized?

Also, you said it yourself in your blog - not caring what is done via
GET and POST is bad practice. Why not enforce this in the engine?

It makes PHP look insecure when apps have security issues because of
poor coding. It's not because PHP itself had a flaw, but to a lot of
people, they see "PHPNuke" or know that postnuke runs under PHP, or
phpbb, etc - the language -can- enforce better techniques, especially
since 5.3 and 6.0 will require some changes in code anyway; this one
is a pretty simple change too -

Someone could make a function like import_request_variables() but
allow it to re-create $_REQUEST and tell people to put it at the top
of their scripts or a central include file if they're too lazy to fix
their code to be more secure. I for one would love to see this be
enforced at the engine level, so that packages I wind up having to use
like Wordpress/etc. have been forced to change their logic (hopefully)
to go back to $_GET, $_POST etc.

Also, I had thought $_REQUEST had included session data too. At least
that is not there. Talk about easy exploitation options then! :)