Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115160 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 16587 invoked from network); 26 Jun 2021 16:01:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Jun 2021 16:01:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id ED5F51804DB for ; Sat, 26 Jun 2021 09:20:59 -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=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 26 Jun 2021 09:20:59 -0700 (PDT) Received: by mail-wr1-f49.google.com with SMTP id g7so9678995wri.7 for ; Sat, 26 Jun 2021 09:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=udYvigdfgY8Eznu/Myb3tUy7Lwdx1u1PNLQnCcT7elc=; b=hfkDneATINNYAHVSh/YVzHQyIUfBLIL5L9Vc+B1ARLRO2LTk8e01rCc7qLoUWTFAhg GerX9nyYoJIve1LIt5wKiHeQKCh39wQkbl2wrIMZHin+DjQJV+eTYtrwZs0BZkxcVYKl kLXqhiAXuVkAh8H2+XL2zuXgPkaxF4dD7b6bOjdlrmnu16qSrZfyJxeV0AfyCqxDdeAu h9A4dnLYfl6uabf26rdH9vmpmHTfG44tWmfBJVRTJZo1iOAFGRMPKkvz7XhfJxTdo9U8 4pLtn46WRZHOcJSG1R+bHQWZmXsFdmQSu32xidFmk6QPOf2W7kDuBV2lSJowfn8omtij 78sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=udYvigdfgY8Eznu/Myb3tUy7Lwdx1u1PNLQnCcT7elc=; b=Ku5i5W5vCGWF40gqsOL+Aj2B9cfr6UFxSwq2pkW3nr10ye2q6V6GoWMbaATf6+/LwJ 3qoT8lweXe6RPgoixit+56+3XT1Ehn7yhfOsmy54EUm9dwhmnKa5y055WyRi/F58Mkp6 cGFSgy+CzXi1/TIXwJxteE7suC8hdsafU3mp4D8k0l0GPXbJf98YXC1yAcapEnzbXm8z HLtxpH3SBjp3x7HCENFPHvUqd/QQ8fYdrvj4WruzeStAfZPr+EsJSYFmUHQrjDKLhpea tN/1PmpO8YqVBy14bY938Cs7mxz9bm5AFdaz58pDFAr7nlWZ4474wjEka/2pwgo/mPtf YsvA== X-Gm-Message-State: AOAM531tbaynIDlLkh4lfJl8ITByhFTQeHoaYE482uPiEiPffaZKwlnv RINnrUMHUzDTjjSiw49ucbUsbz/KcAY= X-Google-Smtp-Source: ABdhPJyKxsGhiYjAoE4DISScTvE9HNc0dwZgcq6r7vFSq5nhaoRQv0dfvD5gslYewZNKd4V9mZwMkQ== X-Received: by 2002:adf:d1cd:: with SMTP id b13mr18390092wrd.228.1624724454289; Sat, 26 Jun 2021 09:20:54 -0700 (PDT) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id g22sm13692062wmh.1.2021.06.26.09.20.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Jun 2021 09:20:53 -0700 (PDT) To: PHP internals References: <95D16F2E-E9DD-4964-A0E2-62E1FB0D976B@koalephant.com> <4DE5E2EC-26D6-4D2C-95A9-B843B440EE87@koalephant.com> <26037CB4-4723-4DC5-BD92-BBDC4F548E17@koalephant.com> <24E12B58-7613-4E67-852C-3312F4AE769C@newclarity.net> <64D2FC1D-E4BA-46E7-A19E-3A7DE35B2096@gmail.com> Message-ID: Date: Sat, 26 Jun 2021 17:20:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted From: rowan.collins@gmail.com (Rowan Tommins) On 26/06/2021 14:47, Dan Ackroyd wrote: > There is a line of code that has a bad assumption of whether $color is > a literal string or not, and it's that line of code that needs to be > changed, to use something that understands HTML escaping, in > particular how to escape user input for html attribute context. All we can say for sure is that the code is making an assertion about its input, and the assertion is failing. It may be that the assertion needs to be revised, and assume that the input is dangerous; or it may be that the assertion is correct and the calling code is violating the contract. Consider this example: function addBlockToSidebar(string $blockHtml): void {     $this->sidebarHtml .= '
' . $blockHtml . '
'; } The contract of this function is that the input is a piece of HTML which isn't under an attacker's control. We can assert that the caller meets that contract either using assert(is_literal($blockHtml)) or by using literal_concat() instead of the . operator. Either way, if that assertion fails, it indicates a bug somewhere else in the program, not in this function, and not necessarily in the call stack of the error: public function getFooBlock(): string {      // literal string, but no assertion is present      $block = '
blah blah
';      if ( isset($this->customBanner) ) {          // $this->customBanner is user-controlled          $block .= $this->customBanner;      }      return $block; } $block = getFooBlock(); addBlockToSidebar($block); Here, the new code in getFooBlock() is at fault, but is not in the stack trace when the assertion fails. Clearing the flag on all concatenations makes no difference to this example: the concatenation is with a non-literal string, so clears it anyway. Regards, -- Rowan Tommins [IMSoP]