Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115458
MIME-Version: 1.0
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
 <CADyq6s+eu4bLM3Z+28Vd0BoGzdbXRyG2Hw9OXqQtyok32p1CJQ@mail.gmail.com>
In-Reply-To: <CADyq6s+eu4bLM3Z+28Vd0BoGzdbXRyG2Hw9OXqQtyok32p1CJQ@mail.gmail.com>
Date: Sat, 17 Jul 2021 17:48:26 +0100
Message-ID: <CAFv4g+H2Eec0SXif3=0nP4wwEaXzggTEPxJjm7fmuwQCR3CFFw@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c5ac3005c75479f9"
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000c5ac3005c75479f9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 17 Jul 2021 at 4:05 pm, Marco Pivetta <ocramius@gmail.com> wrote:

> my belief is that this is not a runtime problem, but rather a type-level
> issue with tainted/untainted input/output.
>


Thank you for the feedback Marco,

As you appreciate, I don=E2=80=99t believe we can get every PHP developer t=
o use
Static Analysis. It=E2=80=99s an extra step that developers with less time,=
 energy,
or care, will not setup and use.

Putting something in the base language, means that libraries can just use
it, and people using the sites/systems of rushed or lazier developers will
have these checks helping keep their data secure. Data breeches can have
life-changing consequences for people, Injection Vulnerabilities are one of
the biggest causes of them, and since we have the ability for libraries to
warn all developers about these mistake, we should.

At the moment our house can catch on fire and we don=E2=80=99t even have a =
smoke
alarm. This is the smoke alarm. And there are reasons why it=E2=80=99s buil=
ders and
landlords that have to install them, and we don=E2=80=99t rely on the tenan=
ts going
and sorting them out themselves. Because if they don=E2=80=99t, for the bes=
t or the
worse reasons, either way there are severe consequences to everybody.

In regards to Taint Checking, it has a significant problem as it creates a
false sense of security, hence these examples in the RFC:

$sql =3D 'SELECT * FROM users WHERE id =3D ' . $db->real_escape_string($id)=
; //
INSECURE

$html =3D "<img src=3D" . htmlentities($url) . " alt=3D'' />"; // INSECURE

$html =3D "<a href=3D'" . htmlentities($url) . "'>..."; // INSECURE

Fortunately Psalm has just implemented the is_literal() concept, so those
developers who do use Psalm can protect themselves from these issues:

https://github.com/vimeo/psalm/releases/tag/4.8.0



In addition to that, a mechanism to un-taint values is missing,
>


That=E2=80=99s the main flaw with Taint Checking, because it=E2=80=99s not =
possible to mark
something as safe without knowing about the context. As in, developers use
an escaping function (to mark as untainted), think the value is now =E2=80=
=9Csafe=E2=80=9D,
and incorrectly use that value in a way that causes a security
vulnerability.

is_literal() simplifies this problem considerably, by just identifying
developer defined strings, and instead using libraries to handle user
values.

Craig

--000000000000c5ac3005c75479f9--