Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118636
Message-ID: <43203091-7b29-fdcf-9811-2206b22ff867@bastelstu.be>
Date: Wed, 14 Sep 2022 22:16:58 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Mel Dafert <mel@dafert.at>, internals@lists.php.net
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
 <9e222608-b142-0b54-5efe-812daeb8780c@bastelstu.be>
 <7B9B123B-47D9-4D7E-B6EF-FD297D3A71CB@dafert.at>
In-Reply-To: <7B9B123B-47D9-4D7E-B6EF-FD297D3A71CB@dafert.at>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 9/14/22 21:58, Mel Dafert wrote:
> Thank you, this makes a lot of sense to me.
> I assume that this rules out that option, at least for now, unless someone makes the relevant changes to the hashing.

You are assuming correctly. That limit was specifically introduced to 
protect against this attack and is specifically documented as such in 
https://www.php.net/manual/en/info.configuration.php#ini.max-input-vars:

 > Use of this directive mitigates the possibility of denial of service 
attacks which use hash collisions.

It *might* be feasible to raise the default value nowadays, because of 
increased processing power moving the point where it "gets bad" further 
upwards.

-----

> But this also means that aborting the request would be just as effective at protecting such an attack as truncating.

Yes. It might or might not be worse with regard to user experience, 
though (not that the truncating behavior is any good either). See also 
my reply to Jordan's email.

> Would aborting instead of truncating introduce any new attack surface?

I don't see how that would add to the attack surface if implemented 
correctly.

> The only thing I could think of would be a DoS vector, but I believe there are a lot of ways you can get a server to instantly abort your request...

If you are only able to abort processing of your own request, then it's 
not even a DoS vector, as you don't affect other users and processing a 
regular request certainly is going to be more expensive on the server 
(database connections and similar) compared to aborting before your 
script starts executing.

Best regards
Tim Düsterhus