Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115058
Date: Wed, 23 Jun 2021 12:19:35 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <7D9709D1-2607-4CC5-8B99-A2CB5ED22E47@newclarity.net>
References: <CAFv4g+GjXqiZkA2fawt7jHDtDAKjB0rv=Lfbcobu7bn8B=wvpw@mail.gmail.com> <CAGa2bXbGv33zHfRpu-hN_wNcNKPpFw_ed1ZRnn96tpDf0ROcLg@mail.gmail.com> <0CD1762E-6094-4DEB-B1B5-22CFBDAAFF44@php.net> <CAG9XoMQUUYGhA6QL3Se4FNJgydjzX0MAeR_CWr5O1SH8xgypLA@mail.gmail.com> <7D9709D1-2607-4CC5-8B99-A2CB5ED22E47@newclarity.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <8EFB7341-CD68-40E8-9DB2-B310DEFB6921@gmail.com>
Subject: Re: [PHP-DEV] [RFC] is_trusted - was is_literal
From: rowan.collins@gmail.com (Rowan Tommins)

On 22 June 2021 10:09:50 BST, Mike Schinkel <mike@newclarity=2Enet> wrote:
>For my inspiration take a look at Trusted Types API in Javascript:
>
>https://developer=2Emozilla=2Eorg/en-US/docs/Web/API/Trusted_Types_API
><https://developer=2Emozilla=2Eorg/en-US/docs/Web/API/Trusted_Types_API>


There is an extremely important difference here: there is no single type i=
n that system called "TrustedString", there are separate types for each con=
text ("injection sink")=2E The W3C article calls this out explicitly:

> Note: This allows the authors to specify the intention when creating a g=
iven value, and the user agents to introduce checks based on the type of su=
ch value to preserve the authors' intent=2E For example, if authors intend =
a value to be used as an HTML snippet, an attempt to load a script from tha=
t value would fail=2E

This is not just an implementation detail, it's an absolutely essential pa=
rt of the concept=2E



So let me add my name to the chorus saying that is_trusted() is a bad name=
, and the added features that led to its selection make this feature worse =
not better=2E



Most of a "trusted types" implementation can be written in pure PHP, becau=
se all you need is an object with a private string property and some approp=
riate constructors=2E=20

The one part you can't do is trust strings provided in source differently =
from strings provided by the user, and the original proposal provided a str=
aightforward mechanism for that purpose=2E

There is no reason why is_literal itself needs to know about "trusted valu=
e objects", or have a long list of special cases to construct a string that=
 is "not actually a literal but we can't think of any way to exploit it"=2E=
 That can all be handled by the userland code:

* Create a class called TrustedSql
* Accept a parameter of type string|TrustedSql=2E If the parameter is a st=
ring, reject it if is_literal returns false
* Or, if a pseudo-type is provided as well, just accept literal_string|Tru=
stedSql
* If the user wants to provide dynamic SQL, they need to construct a Trust=
edSql object using whatever mechanism the library wants to provide=2E That =
can include an audited sprintf pattern, imploding arrays of integers, whate=
ver turns out to be useful=2E


I think the engine should leave the complexities of defining "trusted" to =
APIs specialising in a particular "injection sink", and provide the low-lev=
el building block they need, which is the original simple is_literal functi=
on=2E


Regards,

--=20
Rowan Tommins
[IMSoP]