On 14 September 2022 21:39:36 CEST, "Tim Düsterhus" <t...@bastelstu.be> 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 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
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. But this also means that aborting the request would be just as effective at protecting such an attack as truncating. Would aborting instead of truncating introduce any new attack surface? 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... Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
