Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118634
Message-ID: <a7544016-5520-2598-06ec-5715064d84ba@bastelstu.be>
Date: Wed, 14 Sep 2022 21:55:19 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
 <7e250e89-c18e-9e1a-222a-60521dd2babb@nunninger.info>
 <DEC09231-FDEB-4EDC-A8F3-B9F714112480@dafert.at>
 <6aa89b49-fde5-4779-94e4-97b8b856d02e@www.fastmail.com>
 <CAMrTa2EKkDER30fkpinOgKkHMLTH-QgPEZai0u-9VfTon9c_1A@mail.gmail.com>
 <a82a0fce-2a37-8187-b028-52f989557a2e@bastelstu.be>
 <CAMrTa2Fd7Lu59nOY_SHDkTvg19kn-kf=+ZoU51AgL8cXvD-mMQ@mail.gmail.com>
In-Reply-To: <CAMrTa2Fd7Lu59nOY_SHDkTvg19kn-kf=+ZoU51AgL8cXvD-mMQ@mail.gmail.com>
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:38, Jordan LeDoux wrote:
> the ML, since I'm not suggesting there is a problem, I'm mostly just
> wondering if someone with more expertise can confirm that it isn't an issue.
> 

As indicated by the phrasing in my previous email, this knowledge does 
not enable an attacker to do anything that they wouldn't be able to do 
otherwise. I would also expect that at least the value of the INI 
setting is going to be the default value of 1000 for the vast majority 
of installations out there.

This is primarily an issue of user experience: A user's input data might 
not be correctly processed without the user or the PHP application being 
aware of it.

This incorrect processing might have security implications, e.g. when an 
application uses checkboxes to remove users from a group with elevated 
permissions, the admin checks more than 1000 users and the application 
does not remove the excess users from the group, despite the user making 
extra sure to double check that they checked all the users.

Thus to answer Larry's question, a reasonable action the script could 
take is: Show a non-technical well-styled error message to the human, 
instead of aborting the request with a 500 or silently causing "data 
corruption".

Best regards
Tim Düsterhus