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 attack and is specifically documented as such in https://www.php.net/manual/en/info.configuration.php#ini.max-input-vars:
> Use of this directive mitigates the possibility of denial of service attacks which use hash collisions.
It *might* be feasible to raise the default value nowadays, because of increased processing power moving the point where it "gets bad" further upwards.
-----
But this also means that aborting the request would be just as effective at protecting such an attack as truncating.
Yes. It might or might not be worse with regard to user experience, though (not that the truncating behavior is any good either). See also my reply to Jordan's email.
Would aborting instead of truncating introduce any new attack surface?
I don't see how that would add to the attack surface if implemented correctly.
The only thing I could think of would be a DoS vector, but I believe there are a lot of ways you can get a server to instantly abort your request...
If you are only able to abort processing of your own request, then it's not even a DoS vector, as you don't affect other users and processing a regular request certainly is going to be more expensive on the server (database connections and similar) compared to aborting before your script starts executing.
Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
