Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106629
MIME-Version: 1.0
References: <CAFv4g+EG6f9e6yJqp1sesbJstYJwpdkVso3CKjAD_EAkcrtHqA@mail.gmail.com>
 <CAKuGYLQLEkWhCapqc368jjbi7oGZLjqf6uRkXXWJ5fadLtxc-g@mail.gmail.com>
In-Reply-To: <CAKuGYLQLEkWhCapqc368jjbi7oGZLjqf6uRkXXWJ5fadLtxc-g@mail.gmail.com>
Date: Thu, 15 Aug 2019 20:20:45 +0100
Message-ID: <CAFv4g+EvygJyv0mF4OSBb7iJWrFCkoE800JZtgt-AbnWn+9thQ@mail.gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e2739005902cc5e0"
Subject: Re: [PHP-DEV] Literal / Taint checking
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000e2739005902cc5e0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 15 Aug 2019 at 7:43 pm, Matthew Brown <matthewmatthew@gmail.com>
wrote:

> There are already some userland taint-checking solutions for PHP e.g. the
> Phan taint-check plugin from MediaWiki:
> https://www.mediawiki.org/wiki/Phan-taint-check-plugin
>
> I'm working on my own userland solution, too (based on Facebook's
> approach). Demo is here: https://psalm.dev/r/ebb9522fea
>

Hi Matthew,

If anything, this proposal would help user-land solutions (it gives them
more information while the code is in running).

At the moment, they all need to make their own parsers, or extensions, and
they all have blind spots.

I=E2=80=99d also like us to move slowly away from taint checkers that allow=
 for
tainted strings to be marked as un-tainted, as these allow mistakes to be
made.

Please excuse any typos, on my phone, but how about:

$sql =3D =E2=80=98... WHERE id =3D =E2=80=99 . mysqli_real_escape_string($d=
b, $_GET[=E2=80=98id=E2=80=99]);

It=E2=80=99s been escaped, so surely it=E2=80=99s not tainted any more?

Unfortunately, because it=E2=80=99s not surrounded with quote marks, it=E2=
=80=99s not safe.

It also relies on there not being any parsing issues within the database
engine itself (parameterised queries help here, as those values aren=E2=80=
=99t part
of the SQL parsing process).

Craig

--000000000000e2739005902cc5e0--