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
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
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
Hello everyone. I would like to announce that the RFC for "StreamWrapper
Support for glob()" is now ready for Discussion.
RFC
https://wiki.php.net/rfc/glob_streamwrapper_support
Feature Request and Discussions
https://github.com/php/php-src/issues/9224
Regards,
Tim
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
Hi Timmy,
Good suggestion.
This seems like a no brainer, and definitely good to add streams support
for glob filepaths. You're right, we currently have to work around this in
userland. Your code example workaround is super ugly :)
I'm intersted to know, from others, if there are deeper technical
On Sat, Sep 3, 2022, at 5:38 PM, Larry Garfield wrote:
> In case some people didn't see it in the previous thread, I am bumping
> this poll:
>
> https://docs.google.com/forms/d/e/1FAIpQLSefq15VvGNIXSnQaMTl3RW451w0E8oesny8c4PLqmKl8HhQ-Q/viewform
>
> This is an informal poll on behalf of Ilija and 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 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
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 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/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
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
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: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
2MB is probably too low and it can be set at something like 20MB,
but from my understanding setting it low enough will help prevent DoS
attacks.
If we change it to something larger, I'm not sure exactly what would be
the effect of changing this default for mass-hosting providers where
they can hav
16 matches
Mail list logo
