Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain craigfrancis.co.uk designates 209.85.212.169 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <55CA88A4.4050407@gmx.de>
Date: Thu, 13 Aug 2015 12:00:41 +0100
Cc: Anthony Ferrara <ircmaxell@gmail.com>,
 Julien Pauli <jpauli@php.net>,
 Matt Tait <matt.tait@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <37CFFAF1-52CD-40E5-9C60-71F6F7ADA59C@craigfrancis.co.uk>
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> <B2B729F9-DD03-4FD7-9AA1-FA35F1F764FE@gmail.com> <882D42B0-3554-4CAC-9EB9-09A0F00A35E8@craigfrancis.co.uk> <55CA88A4.4050407@gmx.de>
To: Christoph Becker <cmbecker69@gmx.de>
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: craig@craigfrancis.co.uk (Craig Francis)

On 12 Aug 2015, at 00:43, Christoph Becker <cmbecker69@gmx.de> wrote:

> On 10.08.2015 at 11:57, Craig Francis wrote:
>=20
>> You only have to skim read things like the second comment (with 27 up =
votes) on the PDO prepare page to see that these problems are happening =
all the time:
>>=20
>>=20
>> 	http://php.net/manual/en/pdo.prepare.php#111458
>> 	SELECT * FROM users WHERE $search=3D:email
>=20
> "Skim reading" things might be the problem (here).  The user =
contributed
> note states:
>=20
> | In my case I allow the user to enter their username or email,
> | determine which they've entered and set $search to "username" or
> | "email". As this value is not entered by the user there is no
> | potential for SQL injection and thus safe to use as I have done.
>=20
> So to me that note looks pretty fine.



But that is the problem, many "programmers" (and I know I don't have =
numbers to back this up) do just skim read the docs. They often have a =
problem, and do little research to solve that immediate problem (i.e. =
make it run, don't care what it does or how it does it).

I say this as someone who is frequently finding issues that just should =
not be happening. But at the moment there is nothing that helps =
developers identify those problems or mistakes (with the possible =
exception of static analysis).

Craig