Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.net designates 213.165.64.20 as permitted sender)
Message-ID: <4993154D.4050605@gmx.net>
Date: Wed, 11 Feb 2009 19:13:33 +0100
User-Agent: Thunderbird 2.0.0.19 (X11/20081209)
MIME-Version: 1.0
To: PHP Internals List <internals@lists.php.net>
References: <ce6b011c0902091827q7ea25724u5f6c2de24c9c7713@mail.gmail.com> <20090211161147.GA13632@panix.com>
In-Reply-To: <20090211161147.GA13632@panix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC for new INI's
From: chris_se@gmx.net (Christian Seiler)

Hi,

> variables_order:  They should be the same on dev and prod.
> 
> request_order:  Seems like it should be the same.

Caution! I've read several times in this thread that request_order
should be set to something that also contains C. This is DANGEROUS.
request_order was specifically introduced to determine the order of
variable merging that leads to $_REQUEST, while variables_order defines
the variables that are assigned *at all* (and without register_globals
and with request_order, the _order is actually misleading).

So: request_order should *ONLY* be set to "GP" in order NOT to have
cookies popping up in $_REQUEST - else everybody who uses $_REQUEST is
vulnerable to CSRF.

Also, a recommendation for request_order only makes sense as "GP" (on
both production *and* developement machine) and setting variables order
to "GPCS".

Furthermore, the comment in the ini file that request_order is in there
for performance reasons is just PLAIN WRONG and gives the impression
that setting it to "GPCS" or empty will just cost a little performance -
where it clearly allows for CSRF if people use $_REQUEST.

Regards,
Christian