Re: Error behaviour for max_input_vars

On 14 September 2022 21:39:36 CEST, "Tim Düsterhus" <tim@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