On 14 Sep 2022, at 20:55, Tim Düsterhus wrote:
> 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.
One possibility... when you say the attacker is able to "not send all the
fields", would t
> Le 13 sept. 2022 à 19:58, Mel Dafert a écrit :
>
> In summary, I believe this can only be solved inside of PHP itself, by
> allowing to configure a way for `max_input_vars` to abort the request instead
> of truncating the input.
> The options I see feasible are:
> - A new ini setting `max_i
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
On 14 September 2022 21:39:36 CEST, "Tim Düsterhus" wrote:
>Hi
>
>On 9/13/22 19:58, Mel Dafert wrote:
>> - Deciding that `max_input_vars` is not relevant anymore and should be
>> handled by the likes of Apache and NGINX, thus changing the default to
>> `0` and removing the setting
>> over a
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 anyt
Hi
On 9/13/22 19:58, Mel Dafert wrote:
- Deciding that `max_input_vars` is not relevant anymore and should be
handled by the likes of Apache and NGINX, thus changing the default to
`0` and removing the setting
over a deprecation period.
This would be my preferred option, but my understan
On Wed, Sep 14, 2022 at 12:33 PM Tim Düsterhus wrote:
> Hi
>
> On 9/14/22 20:44, Jordan LeDoux wrote:
> > 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 c
Hi
On 9/14/22 20:44, Jordan LeDoux wrote:
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 scr
On Wed, Sep 14, 2022 at 11:38 AM Larry Garfield
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, i
On Wed, Sep 14, 2022, at 12:07 PM, Mel Dafert wrote:
> On 14 September 2022 16:44:33 CEST, Thomas Nunninger
> wrote:
>>Hi,
>>
>>> In summary, I believe this can only be solved inside of PHP itself, by
>>> allowing to configure a way for `max_input_vars` to abort the request
>>> instead of trunc
On 14 September 2022 16:44:33 CEST, Thomas Nunninger
wrote:
>Hi,
>
>> In summary, I believe this can only be solved inside of PHP itself, by
>> allowing to configure a way for `max_input_vars` to abort the request
>> instead of truncating the input.
>> The options I see feasible are:
>> - A new
On Tue, Sep 13, 2022 at 4:01 PM Derick Rethans wrote:
> On 13 September 2022 19:36:15 BST, juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
> >El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
> >dev.juan.mora...@gmail.com> escribió:
> >
> >>
> >>
> >> El mar., 13 de septie
Hi,
In summary, I believe this can only be solved inside of PHP itself, by
allowing to configure a way for `max_input_vars` to abort the request
instead of truncating the input.
The options I see feasible are:
- A new ini setting `max_input_vars_abort` (default to 0), which, if set
to 1, will
Hello,
Le mardi 13 septembre 2022, 19:58:42 CEST Mel Dafert a écrit :
> Hi internals,
>
> I recently ran into issues with the ini setting `max_input_vars`.
> By default, it will truncate input variables in `$_POST` etc. to the
> first 1000, and issue a E_WARNING.
I also ran into this a few years
El mar., 13 de septiembre de 2022 20:01, Derick Rethans
escribió:
> On 13 September 2022 19:36:15 BST, juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
> >El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
> >dev.juan.mora...@gmail.com> escribió:
> >
> >>
> >>
> >> El mar.,
On 13 September 2022 19:36:15 BST, juan carlos morales
wrote:
>El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
>dev.juan.mora...@gmail.com> escribió:
>
>>
>>
>> El mar., 13 de septiembre de 2022 14:58, Mel Dafert
>> escribió:
>>
>>>
>>> In summary, I believe this can only be solve
On 13.09.22 20:29, Jordan LeDoux wrote:
On Tue, Sep 13, 2022 at 10:59 AM Mel Dafert wrote:
(This happens in the legacy application I am working on, I do
not
see it changing anytime soon.)
All of these solutions would be available in some future version of
PHP. While your
El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
dev.juan.mora...@gmail.com> escribió:
>
>
> El mar., 13 de septiembre de 2022 14:58, Mel Dafert
> escribió:
>
>>
>> In summary, I believe this can only be solved inside of PHP itself, by
>> allowing to configure a way for `max_input_v
El mar., 13 de septiembre de 2022 14:58, Mel Dafert
escribió:
>
> In summary, I believe this can only be solved inside of PHP itself, by
> allowing to configure a way for `max_input_vars` to abort the request
> instead of truncating the input.
> The options I see feasible are:
> - A new ini setti
On Tue, Sep 13, 2022 at 10:59 AM Mel Dafert wrote:
>
> (This happens in the legacy application I am working on, I do not
> see it changing anytime soon.)
>
>
All of these solutions would be available in some future version of PHP.
While your situation highlights something that might be broad
On Tue, Sep 13, 2022, 7:58 PM Mel Dafert wrote:
> The options I see feasible are:
> - A new ini setting `max_input_vars_abort` (default to 0), which, if set
> to 1, will abort the request if there are more input variables than
> allowed.
> - A method to reliably detect whether the input vars were
Hi internals,
I recently ran into issues with the ini setting `max_input_vars`.
By default, it will truncate input variables in `$_POST` etc. to the
first 1000, and issue a E_WARNING.
The form I was using had an extremely big multiselect, where in one case
around 1000 options were actively se
22 matches
Mail list logo
