Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87672
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.49 as permitted sender)
References: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com> <CAMUwpuTJKO+JCWgiVMYRxGDbj1qdhR3Dvoho004KUh_MJoZD4g@mail.gmail.com> <CAAyV7nExkQtPd3Z0hdYp_+iF8ATsLu0itBrXCQX0zntr9y4eCA@mail.gmail.com> <CAEZfaM5kaMLv9y7T0C9E2Xi=AUuHwAFosjd8wGf6QQ120Pi46Q@mail.gmail.com> <CAAyV7nFsqNkbQwCd85p3uAxY4RrPemnqUYktcuT1Xmg50xfdWQ@mail.gmail.com> <CAEZfaM6jF=iW2Cc=kNxyFZ4B-HES9aH9ywNWzRXvXOx++06Cag@mail.gmail.com> <CAAyV7nGEy8fBYPvDqwmP+3FDSEBqjN9=0gfnbWvOSK6A1c6YJw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAAyV7nGEy8fBYPvDqwmP+3FDSEBqjN9=0gfnbWvOSK6A1c6YJw@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <B2B729F9-DD03-4FD7-9AA1-FA35F1F764FE@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Date: Thu, 6 Aug 2015 15:57:53 -0700
To: Anthony Ferrara <ircmaxell@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack
From: matt.tait@gmail.com (Matt Tait)

Thanks for the feedback Anthony,

This feature specifically addresses the points you raise; the feature allows=
 parameterized queries constructed with structural parts of the query insert=
ed from configuration variables, so long as the resulting query is a safe-co=
nst as defined by this RFC.

If you can come up with an example of a query that either (a) is vulnerable t=
o a SQL injection attack and this feature wrongly does not detect it as such=
 or (b) a query that cannot be expressed using parameterized queries where t=
he parameter is a safe-const as defined by this RFC, I'd be genuinely intere=
sted to take a look.

Hope that clarifies,
Matt

> On Aug 6, 2015, at 14:34, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>=20
> Matt,
>=20
>> You are of course welcome to disagree with the overwhelming body of secur=
ity
>> advice that parameterized queries are the correct, secure way to prevent S=
QL
>> injection. In that case, you only need to not enable this feature. This
>> feature is off-by-default, and only attempts to help secure webapplicatio=
ns
>> and webdevelopers who do (or are required, for example by PCI compliance
>> standards) to adopt this security-best-practice to ensure that they do so=

>> systematically across their entire website.
>=20
> You seem to misunderstand me. I'm *not* saying that you shouldn't use
> parameterized queries. Nor that they are not one of the best tools
> available. I am simply pointing out that they are not a sure-fire
> one-stop solution. There is a lot more that goes into it than simply
> using prepare/bind. As indicated by the two cases I talked about
> (structural elements not being supported and implementation quirks) as
> well as others (DOS attacks from wildcards in malformed query
> parameters, type validation, etc). This is not to say that we should
> avoid PQ, but that we should recognize that it's not enough to just
> use one thing and forget about everything else.
>=20
> Anthony
>=20
> PS: w3schools is NOT w3c. And their content is probably the single
> largest source of security vulnerabilities for PHP, so citing them in
> a security discussion is more than a little ironic.