Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114871 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91573 invoked from network); 14 Jun 2021 20:36:33 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Jun 2021 20:36:33 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4BE741804D1 for ; Mon, 14 Jun 2021 13:52:52 -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,FREEMAIL_FROM,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-Virus: No X-Envelope-From: Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 ; Mon, 14 Jun 2021 13:52:51 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id x8so8572272vso.5 for ; Mon, 14 Jun 2021 13:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xnAprDmte3s1lqLzm1WmP7WAgVA7hdKiNv5GhpxsJrg=; b=s7lQoiVahsNqT78nNjHy3EU/al/CenrFBcLcQPb5rWL/l7vJkZIU9rXKRaBer4l0Ru XuKxpEdjH1q1MuAvc7dG5yi8bTUiEFcKYplhW7GbONndylVsLwacpqqUwoSpi7sAaqPe nQjMMdRsuDJdLpzDv53TVkcDoaCQzHSYrTx92waZkMVlvJWq4DfvEDeS/64jqRHHDH+g HUFB8gufPi6jRN/PWdHbBWrNWxfJIFzfjaHirLyIX4iCWG55gNRXxboXchx+mO2EYUwz SqyvbTEksdJusRFHu1GFrjURpHR7JM7sjGtnTrIXB0wAcNRoaEKOPlVbvdA/krMxhRyv asAA== 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=xnAprDmte3s1lqLzm1WmP7WAgVA7hdKiNv5GhpxsJrg=; b=cGiX8Ov+DdEllhlfYyOvblVaWIHVn9TBygJzZ9ASmMRacMZMTM4UjeAOxx4i+qUGO9 r6hQ/LudoRoWukfUT3wunHSLf6GyMshxoa6FdKELMLPmms6EF8H4zdP0Zj2RByGqy2v9 QfWQiuI1QI6VblQt9yrgjzINpwags7cPjHTR8V900MZpFkDjCr7+IwIfNz9Fn+2DWy2j BU4pTZFoHFYqSzXKJaPj67SEQgwUGCU/ZSBDtOb5YzpUHacE2vM3Bsyc6vMcXvjP+9/i ZLUeXfhKAsV2piV3c9tv+uzO4CezH1dEsS4YwujbwfD5uR7dtz1O+1fGtdOSELg7aEnB qzqw== X-Gm-Message-State: AOAM5302H2XWghsP9AFgaIaigR/PkgsmvBIzela839eXNz528RW/ZBF4 T1XsSJFx9MKXswCvWCO8MzGtm+stwcHDUFsRJmAQxTgEKfA= X-Google-Smtp-Source: ABdhPJwOy4VXjIIm1nJWOG49ZCeAryXupLnoRxs/Py1RUD7udjH5gkki0/AD48QlLj7cPjCpcqwafAVcebFECt8UvRQ= X-Received: by 2002:a05:6102:99:: with SMTP id t25mr1318889vsp.48.1623703970107; Mon, 14 Jun 2021 13:52:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 14 Jun 2021 16:52:38 -0400 Message-ID: To: Craig Francis Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000005bd4f805c4c00a20" Subject: Re: [PHP-DEV] [RFC] is_literal From: matthewmatthew@gmail.com (Matthew Brown) --0000000000005bd4f805c4c00a20 Content-Type: text/plain; charset="UTF-8" I've just added support for a `literal-string` type to Psalm: https://psalm.dev/r/9440908f39 This will remain whether or not the RFC passes, but if it passes the is_literal check will be used to inform Psalm in a similar fashion to how array_is_list (coming in 8.1) will inform Psalm's list array type. Adding the literal-string type guard to our main SQL creation endpoint identifies roughly 20% of all DB queries that would _not_ pass the `is_literal` check, and would need to use some sort of explicitly unsafe endpoint. From my perspective biggest issue with the current approach is that implode(', ', [1, 2, 3]) is treated as non-literal. We have a lot of queries that look like WHERE `foo` IN (' . implode(', ', self::ALLOWED_IDS) . ')' and these would all have to take the "unsafe" path, which is a bit annoying. Could you add the same flag to ints, or is that too hard? On Sat, 12 Jun 2021 at 13:00, Craig Francis wrote: > Hi Internals, > > I'd like to start the discussion on the is_literal() RFC: > > https://wiki.php.net/rfc/is_literal > > is_literal() brings a proven way to identify Injection Vulnerabilities to > PHP, already used by Google in their Java and Go projects, and is currently > being added to JavaScript. It's a lightweight and simple approach: > "Distinguishing strings from a trusted developer from strings that may be > attacker controlled", allowing Libraries to identify the mistakes made by > the thousands of developers using them incorrectly. > > When Libraries use is_literal() to protect against these mistakes, we can > trust their output, and (as covered in the Future scope section) PHP can > then raise warnings with certain native functions like PDO::query, > mysqli_query, exec, preg_match, etc. (we would only consider warnings, > anything stricter like exceptions would be in many years time, if at all - > the intention is to alert and inform people, not break things). > > The length is due to the FAQ Section, on why it's needed, how it can be > used by Libraries, and the important differences of using this flag versus > the flawed Taint Checking approach with its false sense of security > (error-prone escaping). > > Thanks, > Craig Francis > > > PS: If anyone wants to discuss face-to-face on Zoom, I'll be available (UK > Time/BST/UTC+1) at: > > https://chat.craigfrancis.co.uk/ > > Saturday 12th June, 6pm to 8pm; > Sunday 13th June, 10am to Midday; > Monday 14th June, 5pm to 7pm; > Tuesday 15th June, 9pm to 11pm; > Thursday 16th June, 10am to Midday; > (other times on request) > --0000000000005bd4f805c4c00a20--