Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118630
MIME-Version: 1.0
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>
In-Reply-To: <6aa89b49-fde5-4779-94e4-97b8b856d02e@www.fastmail.com>
Date: Wed, 14 Sep 2022 11:44:23 -0700
Message-ID: <CAMrTa2EKkDER30fkpinOgKkHMLTH-QgPEZai0u-9VfTon9c_1A@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000015e3ce05e8a7856f"
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000015e3ce05e8a7856f
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 14, 2022 at 11:38 AM Larry Garfield <larry@garfieldtech.com>
wrote:

>
> I think the key question here is if there is a reasonable action the
> developer could take if an over-sized request came in.  PHP itself can dump
> that to the log, but is there anything reasonable beyond that the developer
> could do, if they could detect it?
>
> And is anyone doing that now?
>
> --Larry Garfield
>
>
Honestly, another question I'm thinking about at the moment is whether it's
possible to construct an attack against known script behavior if you also
are able to determine the ini config at which partial form data would make
it to the script with the script thinking it has full form data. To be
clear, I haven't been able to think of one, but I also recognize that I'm
not nearly as clever at those sorts of things as some attackers are.

I suppose that would depend on both the form and the script though.

Jordan

--00000000000015e3ce05e8a7856f--