Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118633 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 33655 invoked from network); 14 Sep 2022 19:39:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Sep 2022 19:39:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 69DB4180569 for ; Wed, 14 Sep 2022 12:39:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 14 Sep 2022 12:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1663184377; bh=sip1l6OAcEhzWMiQ4FmRlnDy9ALJyjo84rpZUaCrgvA=; h=Date:Subject:To:References:From:In-Reply-To:From; b=cpIAA5l6oVSyz+Wi7+0jQ49yTk33fNe22rZiV7fyHt9iSRoK5HV+K91/79mnos9SX 2u6/fKbIGov1sxTw2EdC+M0mo5+J5D83jS8S5E4zCZ3mzyl5oMSPyiJrgzHs51G/DP WHQ2hTGstBLxe69fWXuxKo8FRBSFIRN3tPytnhFsAo2Dz2jcURDG/EoAj2WpGh0XZt P0qsAFgLLJdViN31twrW7rinkgirfjoEvZW/IutkJw8OPkIu7MiFvE2xdP13TX/zqA u9T4Pnclelz8Kk0vFw3U60VPxdXCbkY2ct6n1lmubx02ij37ikuZsvLKzlAv3njDv8 ZMVHE9SFUlGRg== Message-ID: <9e222608-b142-0b54-5efe-812daeb8780c@bastelstu.be> Date: Wed, 14 Sep 2022 21:39:36 +0200 MIME-Version: 1.0 Content-Language: en-US To: Mel Dafert , internals@lists.php.net References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at> In-Reply-To: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Error behaviour for max_input_vars From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) 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