Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114836
MIME-Version: 1.0
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
In-Reply-To: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
Date: Sat, 12 Jun 2021 19:45:53 +0200
Message-ID: <CAOwTYAt3rztsZ1BTjEbsonqPR_thgG7UqEUO2pKeN=dEg1jqgg@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ba696a05c495328f"
Subject: Re: [PHP-DEV] [RFC] is_literal
From: krakjoe@gmail.com (Joe Watkins)

--000000000000ba696a05c495328f
Content-Type: text/plain; charset="UTF-8"

Afternoon all,

While this is not at all my idea, I wrote the patch, so my words may seem
bias/hollow. Still, here are some words ...

In the past this kind of feature would have been extremely invasive, it
would have had so many edges because of the way we handled strings that it
was never really feasible.

Today the implementation of this is not particularly invasive or
complicated, and it lends a very useful tool to the developer.

This starting place, of second class support seems like a reasonable
starting place, but there is a possible future where we have first class
support.

This may or may not be appealing and we'll be in a better position to judge
when we see how this may be used in the wild.

Cheers
Joe


On Sat, 12 Jun 2021 at 19:00, Craig Francis <craig@craigfrancis.co.uk>
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)
>

--000000000000ba696a05c495328f--