Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58944
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.161.170 cause and error)
Message-ID: <4F6123FD.7020101@lerdorf.com>
Date: Wed, 14 Mar 2012 16:04:29 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP internals <internals@lists.php.net>
References: <4F60F4B1.5010407@lerdorf.com> <4F6117AA.2080004@sugarcrm.com>
In-Reply-To: <4F6117AA.2080004@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 03/14/2012 03:11 PM, Stas Malyshev wrote:
> Hi!
> 
>> The other way to solve this would be to make max_input_vars PHP_INI_ALL
>> and then just let people ini_set() their way around the limit.
> 
> I think making it PHP_INI_ALL is OK. If you have access to a way to
> change INI_ALL vars, that means you can run code on that system, then
> DoS protection is meaningless on this stage.

I ran into this in some existing code that broke upgrading to 5.3.10. It
was a backend call to an API where the API result was being fed to
parse_str(). The API itself is trusted, so no risk of a HashDoS from it.
Other than replacing the call to parse_str() with a similar userspace
implementation there was no way to fix this safely. I could do a
.htaccess for just that URI, but that would open up the frontend of this
particular request to a HashDoS.

I'll make the INI_ALL change for the next release.

-Rasmus