Error behaviour for max_input_vars

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 truncated (eg.
  function has_post_been_truncated(): bool), so the application can
  decide whether to abort or not.
• 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.

Creating more ini settings is not very exciting. I do really like option 2
though.

 (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 broadly applicable
to PHP, you'd likely have to update the legacy application to take
advantage of any solution that was eventually included so that it could run
on the most recent version of PHP. Unless you're suggesting that this would
also be backported? 7.4 falls out of all support in a few months.

Just want to make sure you're aware of how the inclusion process would work
for any solution to this issue.

Jordan

El mar., 13 de septiembre de 2022 14:58, Mel Dafert mel@dafert.at
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 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 truncated (eg.
  function has_post_been_truncated(): bool), so the application can
  decide whether to abort or not.
• 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.

I am leaning towards the first option, but would be open to either outcome.

We should not delete the ini setting "max_input_vars"... Is a breaking
change very hard.

I Am in favour of adding More flexibility about how to handle this
situation... And I also think that options 1 and 2 can coexist smoothly.

I suggest you write and RFC for this and continue the discussion on this
e-mail list but with the RFC already created.

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 ago and it is really annoying. I agree we
need a reliable way of catching this error.

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 abort the request if there are more input variables than allowed.
• A method to reliably detect whether the input vars were truncated (eg.
  function has_post_been_truncated(): bool), so the application can decide
  whether to abort or not.
• 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.

All 3 solutions seems a nice improvement from current situation.

Côme

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 abort the request if there are more input variables than
  allowed.
• A method to reliably detect whether the input vars were truncated (eg.
  function has_post_been_truncated(): bool), so the application can
  decide whether to abort or not.
• 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.

I am leaning towards the first option, but would be open to either outcome.

I'd prefer that PHP aborts such requests. Then data loss/inconsistency
is prevented for everybody and people can fix their applications. (So no
need for an ini setting that allows acting in "danger mode".)

If you'd like to give developers more options to choose from, I'd go for
max_input_vars_abort (default 1) plus has_post_been_truncated(): That
way the behavior is safe from the start. And people who opt in for
"danger mode" can reliably detect if there was some data loss and can
deal with it.

Regards
Thomas

Hi

• 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 understanding is that the
limit still is relevant to protect against attacks on the hash table
implementation. The web server can't really protect against this type of
attack, because the payload required to execute the attack is fairly
small. Protecting against the attack without some arbitrary cut-off
limit would require making the hash algorithm used for the superglobals
dependent on a randomly generated per-request seed value. I can't
comment on how easy or hard that would be to change, but I believe that
this should be the ultimate goal here. It's also what other programming
languages do.

Best regards
Tim Düsterhus

Le 13 sept. 2022 à 19:58, Mel Dafert mel@dafert.at 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_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 truncated (eg. function has_post_been_truncated(): bool), so the application can decide whether to abort or not.
• 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.

I am leaning towards the first option, but would be open to either outcome.

Hi,

A big issue with max_input_vars (and indeed any fallible procedure executed at startup) is that errors occur before that the program has a chance to install a custom error/exception handler or to open a try/catch block.

For the specific case of $_POST, a possible option would be:

• set the ini setting enable_post_data_reading to false, so that $_POST and $_FILES are not populated at startup;
• have a function that to enable to populate those variables at runtime:

try {
    read_post_data([ 'max_input_vars' => 100_000 ]);
}
catch (\TooManyInputVarsException) {
    // custom panic procedure
}

A more general solution would be to be able to retrieve all errors (not just the last) that has been triggered at startup, e.g.:

set_error_handler('app_specific_error_handler');
replay_error_triggered_at_startup(); // will re-trigger all errors that has occurred before the first line of code

—Claude