Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108977 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60370 invoked from network); 11 Mar 2020 14:48:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Mar 2020 14:48:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6E1FC1804E6 for ; Wed, 11 Mar 2020 06:09:53 -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,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) (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 ; Wed, 11 Mar 2020 06:09:52 -0700 (PDT) Received: by mail-wr1-f68.google.com with SMTP id t11so2546130wrw.5 for ; Wed, 11 Mar 2020 06:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=craigfrancis.co.uk; s=default; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xx4QVISw0fwwvP9XWS8mnV6oBiuQBhSV0HUazNlF7ig=; b=LPr1CqPwy0YtdTMcuA+MgbNTqw+Z9i55MpmzJ0xj82HgHvRYuYsh1fX1y64YVr9gf0 GsR1lrQpCqCy1gG0rqn2JP7MHMPmQf2Pr/nlVY1rbJTj/IdqUC41K//enVE6/GsAHbRC Qb3eAbBPI1d51MZiONasskUZ/yDkpeAuQad+U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xx4QVISw0fwwvP9XWS8mnV6oBiuQBhSV0HUazNlF7ig=; b=sbPfNCIiyV7KGNPyMT6A7Gpc4lOkwR8YRLRcGrsjDo3hUkBM8m0dWNin6oNViQrZBm L7RzyHbwSAD4U5dxgcOAO4EKq+nvFtScImrPKXwuBk1pkCU/APcbckOfit3X77cPXL49 ElTl/qUj8TVpO6gJrfCKJL2uzcqESk6fM4nVc5WMGYZfohCE01+sK3wQ/tuFtMlEFm2w 0N4/C2/oogs/N1I6bIvB79AOFWye5KbT7vvngZyIpGm+Y1t3cJPUvUY36uelYmMzFF8Y 3kCwMQnzjZzh4ymbZcxsJqGnsSo82ojeKdfu2pooZ7F+yJM9T5x4n7bx6Y13LAYTluOE SApQ== X-Gm-Message-State: ANhLgQ17w5LsCIO5SpRS1hclh1Ei+RDvg/PpKFGSIge52SNE4XURecR+ qWRmjwPNSuZwIleL2a3O5hfWQxXG3Rs/MIOGkEBSHg== X-Google-Smtp-Source: ADFU+vuPVqOI0QClzJYQ9gvOjGWcuixSpSZrred1Kfv7L9/l2xWaBdTJV42yd11+Dv31vINP4sQFRefKQFRU+vlNrXM= X-Received: by 2002:adf:f5cb:: with SMTP id k11mr4417747wrp.214.1583932187155; Wed, 11 Mar 2020 06:09:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 11 Mar 2020 13:09:36 +0000 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000005d2fee05a093f33d" Subject: Re: [PHP-DEV] Re: Literal / Taint checking From: craig@craigfrancis.co.uk (Craig Francis) --0000000000005d2fee05a093f33d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 9 Mar 2020 at 16:54, Rowan Tommins wrote: > [...] the way to get a more in-depth discussion going is to draft an RFC Thanks Rowan, I've created a Wiki account (craigfrancis), and I believe the next step is to ask for RFC karma? And is there is anyone who can help with the technical details? I'd really appreciate it. If it helps, I've got a development budget of =C2=A31,000 I = could put towards this (I will need an invoice, a simple PDF would do). As to the discussion around the older RFC[1]... The last message I can find was on the 1st September 2015[2]. The RFC focused on SQL injection, where it was noted that "unfiltered input can affect way more than only SQL"[3], and it isn't ideal for "just for one use case"[4] - my proposed `is_literal()` can be used for other issues, such as Cross-Site Scripting[5], Command Line Injection, etc. There was a belief that education was the answer[6] - but having this check would allow developers to identify (and block) mistakes at runtime. Xinchen mentioned how it was complex in PHP5 to implement the Taint extension - but "with PHP7's new zend_string, and string flags, the implementation will become easier"[7]. And while the Taint checking is useful, it does not address the mistakes that can happen with escaping. As to why I'm deviating away from the original RFC... By providing a `is_literal()` function, it allows the developer to determine how they want to use it - where they can skip it for certain tasks[8], and database drivers (or other extensions) could use it in the future to raise a notice/warning/error[9]. It gives a mechanism to ensure inputs are split between the command (a literal), and user supplied values - which is what Yasuo was asking for[10]= . Also, by focusing on just literals (as in, only values defined within PHP scripts), we avoid any concerns about escaping (which can go wrong), and we won't need to identify which sources are trusted[11]. For the last 5 years I've been writing my SQL with literals only, and it's worked very well... with just one oddity (which I still consider a literal)= : [1] https://news-web.php.net/php.internals/87346 [2] https://news-web.php.net/php.internals/87970 [3] https://news-web.php.net/php.internals/87355 [4] https://news-web.php.net/php.internals/87647 [5] https://news-web.php.net/php.internals/87400 https://bugs.php.net/bug.php?id=3D79359#1583761206 [6] https://news-web.php.net/php.internals/87383 [7] https://news-web.php.net/php.internals/87396 [8] https://news-web.php.net/php.internals/87406 https://news-web.php.net/php.internals/87446 [9] https://news-web.php.net/php.internals/87436 https://news-web.php.net/php.internals/87650 [10] https://news-web.php.net/php.internals/87725 [11] https://news-web.php.net/php.internals/87667 On Mon, 9 Mar 2020 at 16:54, Rowan Tommins wrote: > On Mon, 9 Mar 2020 at 13:47, Craig Francis > wrote: > > > Hi, > > > > As I'm not sure how to make any more process on this, I've added added = a > > Feature Request: > > > > https://bugs.php.net/bug.php?id=3D79359 > > > > It shows how this change in PHP could stop SQL injection, and proposes = a > > way it could be used against HTML injection as well. > > > > > Hi Craig, > > In my experience, the bug tracker is likely to get you less attention tha= n > this list, rather than more. For this kind of significant change, the way > to get a more in-depth discussion going is to draft an RFC; there are som= e > instructions and tips on how to go about that at > https://wiki.php.net/rfc/howto and > > https://blogs.oracle.com/opal/the-mysterious-php-rfc-process-and-how-you-= can-change-the-web > > The idea of an RFC is to sit down and design exactly how the proposed > feature would work; that helps move the discussion forward, because peopl= e > can see exactly how it might look, and means you're offering something to > the community rather than asking it of them. The RFC doesn't have to > include a full implementation, but if you don't know much about the > technical details, you might need help from someone who does to make sure > the proposal is realistic. > > I see you've linked an older RFC in the feature request; it would be wort= h > digging out the archived discussion from when that was proposed, to see w= hy > it stalled. It may just be that people were distracted by other things, o= r > there may be issues raised which you can consider in a new proposal. If y= ou > haven't already, you could try contacting the author as well. > > In general, I think it's an interesting idea, but as the saying goes "the > devil is in the detail", so I don't have much to say without a concrete > proposal for what it would look like. > > Regards, > -- > Rowan Tommins > [IMSoP] > --0000000000005d2fee05a093f33d--