Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87393
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.178 as permitted sender)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF4E813A-0EB5-4162-8E09-FE79EEB6F7C1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAL=_i_md=Z-0UKF5XWMTFh2mhc6PR6TVHyaOXCshf_wtm-p+ug@mail.gmail.com>
Date: Thu, 30 Jul 2015 13:40:16 +0100
Cc: Lester Caine <lester@lsces.co.uk>,
 PHP internals <internals@lists.php.net>
Message-ID: <1715687D-BA2C-459F-AC98-A9443F468F3D@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> <44415028-F437-4914-818C-C928BA01D7FE@craigfrancis.co.uk> <CAL=_i_md=Z-0UKF5XWMTFh2mhc6PR6TVHyaOXCshf_wtm-p+ug@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
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)

--Apple-Mail=_FF4E813A-0EB5-4162-8E09-FE79EEB6F7C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 30 Jul 2015, at 13:14, Joe Watkins <pthreads@pthreads.org> wrote:

> I find myself agreeing with Pierre; The wrong signal would be sent. =
History should teach us there is no such thing as (a) safe mode.



Hi Joe,

Please can you read my proposal (see the email you just replied to, also =
below)... I'm replying on this thread because my first one was =
ignored... I'm not suggesting a "safe mode" or any kind of blocking of =
requests (as per the subject)... as I agree, and believe that would be =
worse than the old auto escaping from PHP 4.

Craig






On 30 Jul 2015, at 13:14, Joe Watkins <pthreads@pthreads.org> wrote:

> I find myself agreeing with Pierre; The wrong signal would be sent. =
History should teach us there is no such thing as (a) safe mode.
>=20
> Xinchen did used to work on a taint extension, I wonder why that was =
stopped ?=20
>=20
> Worth noticing that the extension is rather complex, touching many =
parts of the engine, changing many things ... which I don't really like.
>=20
> Cheers
> Joe
>=20
> On Thu, Jul 30, 2015 at 10:14 AM, Craig Francis =
<craig@craigfrancis.co.uk> wrote:
> On 30 Jul 2015, at 08:24, Lester Caine <lester@lsces.co.uk> wrote:
>=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
>=20
>=20
>=20
> I completely agree on education, and what I'm hoping for... and this =
is how we can educate everyone :-)
>=20
> 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.
>=20
> While my first post on this mailing list gives a better overview:
>=20
>    http://news.php.net/php.internals/87207
>=20
> The original implementation suggestion is at:
>=20
>    https://bugs.php.net/bug.php?id=3D69886
>=20
> You will see that it does nothing more than create notices to say =
"erm, do you want to be doing this?".
>=20
> This is something that only PHP can do, unless you can find a way of =
changing every single article / code example on the internet :-)
>=20
> 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).
>=20
> 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).
>=20
> Craig
>=20
>=20
>=20
>=20
>=20
> On 30 Jul 2015, at 08:24, Lester Caine <lester@lsces.co.uk> wrote:
>=20
> > On 29/07/15 16:11, Craig Francis wrote:
> >> I completely disagree... prepared statements are just as =
vulnerable, and so are ORM's.
> >>
> >> 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:
> >>
> >>      if ($stmt =3D $mysqli->prepare("SELECT District FROM City =
WHERE Name=3D" . $_GET['name'])) {
> >>      }
> >
> > 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.
> >
> > 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.
> >
> > Educate ... don't nanny ...
> >
> > --
> > 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
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20


--Apple-Mail=_FF4E813A-0EB5-4162-8E09-FE79EEB6F7C1--