Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115472
MIME-Version: 1.0
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
 <CADyq6s+eu4bLM3Z+28Vd0BoGzdbXRyG2Hw9OXqQtyok32p1CJQ@mail.gmail.com>
 <CAFv4g+H2Eec0SXif3=0nP4wwEaXzggTEPxJjm7fmuwQCR3CFFw@mail.gmail.com> <CAMrTa2GVpugjj71tcQO8oJgMyf7A_naHbrakjRWj92oKkAJQOw@mail.gmail.com>
In-Reply-To: <CAMrTa2GVpugjj71tcQO8oJgMyf7A_naHbrakjRWj92oKkAJQOw@mail.gmail.com>
Date: Mon, 19 Jul 2021 09:24:31 +0200
Message-ID: <CAF+90c_pQWD2nN34h9nS5fYmSvmfKkPOThVArpjUvVAO7cDo-w@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: Craig Francis <craig@craigfrancis.co.uk>, Marco Pivetta <ocramius@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000c4c1505c774d539"
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000000c4c1505c774d539
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 18, 2021 at 4:42 AM Jordan LeDoux <jordan.ledoux@gmail.com>
wrote:

> Related to the general topic of injection attacks, I was considering
> submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to
> FALSE, since this mistakenly can lead people to believe that using prepar=
ed
> statements with PDO and MySQL protects against injection attacks. In fact=
,
> this is only the case if they create the PDO object with the option
> specified as false. I'm not aware however to reasoning for enabling prepa=
re
> emulation by default for MySQL. I would assume it's a performance choice,
> but how long ago was this choice made and is it worth revisiting? Would
> this be something that requires its own RFC? It's a single line change.
>
> Jordan
>

Please do refrain from spreading this FUD. While there are certain
tradeoffs between choosing emulated or native prepared statements, security
considerations do not factor into it. There's a very narrow window where
emulated prepared statements can lead to incorrect escaping (it involves
picking an exotic non-ASCII-compatible charset, not specifying it in the
connection DSN, and switching to it at runtime), but it's not something you
can hit by accident.

Regards,
Nikita

On Sat, Jul 17, 2021 at 9:48 AM Craig Francis <craig@craigfrancis.co.uk>
> wrote:
>
> > 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 develop=
er to use
> > Static Analysis. It=E2=80=99s an extra step that developers with less t=
ime,
> energy,
> > or care, will not setup and use.
> >
> > Putting something in the base language, means that libraries can just u=
se
> > it, and people using the sites/systems of rushed or lazier developers
> will
> > have these checks helping keep their data secure. Data breeches can hav=
e
> > life-changing consequences for people, Injection Vulnerabilities are on=
e
> 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 hav=
e a smoke
> > alarm. This is the smoke alarm. And there are reasons why it=E2=80=99s =
builders
> and
> > landlords that have to install them, and we don=E2=80=99t rely on the t=
enants
> going
> > and sorting them out themselves. Because if they don=E2=80=99t, for the=
 best or
> the
> > worse reasons, either way there are severe consequences to everybody.
> >
> > In regards to Taint Checking, it has a significant problem as it create=
s
> 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'' />"; // INSEC=
URE
> >
> > $html =3D "<a href=3D'" . htmlentities($url) . "'>..."; // INSECURE
> >
> > Fortunately Psalm has just implemented the is_literal() concept, so tho=
se
> > 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
> >
>

--0000000000000c4c1505c774d539--