Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87386
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.180 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <55B9D14B.9010902@lsces.co.uk>
Date: Thu, 30 Jul 2015 10:14:49 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <44415028-F437-4914-818C-C928BA01D7FE@craigfrancis.co.uk>
References: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com> <55B896B8.4070901@lsces.co.uk> <6F8B9B35-D487-45D9-BC84-4A782951EDC7@craigfrancis.co.uk> <55B9D14B.9010902@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>
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 30 Jul 2015, at 08:24, Lester Caine <lester@lsces.co.uk> wrote:

> But that is a perfect example of what I am talking about. You do not
> educate people by publishing the very thing that is wrong. You educate
> them by pointing out to them WHY the '?' was there in the first place.




I completely agree on education, and what I'm hoping for... and this is =
how we can educate everyone :-)

My suggestion for taints (not quite the same as the one from Matt or =
Wietse) was not to change the way good programs are created/executed, =
but simply an education device, which can also pick up mistakes that =
experienced developers make.

While my first post on this mailing list gives a better overview:

   http://news.php.net/php.internals/87207

The original implementation suggestion is at:

   https://bugs.php.net/bug.php?id=3D69886

You will see that it does nothing more than create notices to say "erm, =
do you want to be doing this?".

This is something that only PHP can do, unless you can find a way of =
changing every single article / code example on the internet :-)

So, with your example... if you want to use a variable for a table/field =
prefix, that is perfectly fine... in fact, it won't need any changes, as =
the prefix will probably be hard coded as a string within a PHP script =
(something I called ETYPE_CONSTANT).

But if not (e.g. storing the prefix in an ini file?), then I've shown an =
example of how that can be handled with the proposed =
"string_encoding_set" function (something I should have probably called =
string_escaping_set)... which is simply to tell PHP that this one =
variable is already safe (something I can't see being needed very =
often).

Craig





On 30 Jul 2015, at 08:24, Lester Caine <lester@lsces.co.uk> wrote:

> On 29/07/15 16:11, Craig Francis wrote:
>> I completely disagree... prepared statements are just as vulnerable, =
and so are ORM's.
>>=20
>> You can push developers towards these solutions, and that would be =
good, but you are completely blind if you think an uneducated developer =
won't do:
>>=20
>> 	if ($stmt =3D $mysqli->prepare("SELECT District FROM City WHERE =
Name=3D" . $_GET['name'])) {
>> 	}
>=20
> But that is a perfect example of what I am talking about. You do not
> educate people by publishing the very thing that is wrong. You educate
> them by pointing out to them WHY the '?' was there in the first place.
>=20
> Since the taint extension only covers mysql and sqlite it's of little
> use if we manage to convert 'uneducated developer' to any of the more
> secure databases, and that was one of the reasons why mysql was =
dropped
> from being loaded by default. Once one starts from a base of
> parametrised sql queries the lax programming methods many mysql guides
> and books continue to push can be reversed. Throwing more bloat into =
php
> to create 'WTF' errors just adds to a new users frustration and annoys
> experienced users who have very good reasons for building queries =
using
> clean variables. MANY abstraction layers use variables to add prefixes
> to table names or fields.
>=20
> Educate ... don't nanny ...
>=20
> --=20
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20