Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87403
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.179 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: <CABBJUpeWHiRFaSXp0nhintaeaaOVs67kCSnv2rT-t71QMFaZSw@mail.gmail.com>
Date: Thu, 30 Jul 2015 16:20:12 +0100
Cc: Joe Watkins <pthreads@pthreads.org>,
 Lester Caine <lester@lsces.co.uk>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <67D5FE0C-3919-4695-B836-E1B9A553F0E4@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> <CABBJUpeWHiRFaSXp0nhintaeaaOVs67kCSnv2rT-t71QMFaZSw@mail.gmail.com>
To: Xinchen Hui <laruence@php.net>
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 13:47, Xinchen Hui <laruence@php.net> wrote:
> anyway, with PHP7's new zend_string, and string flags, the
> implementation will become easier.



Hi Xinchen,

Glad to hear that you are still looking into this... please let me know =
if there is anything I can do to help (unfortunately I'm not a C =
programer).

Out of interest, if you are going to continue using "taint_marks", as =
the RFC suggested... can I suggest all variables start with 0 (or =
undefined)... then you can set flags as the variables are passed though =
functions like htmlentities and pg_escape_literal?

This way all variables are treated as plain (unsafe), and then =
developers either need to escape them (e.g. when printing to output, or =
using in SQL, CLI, etc), or they can mark them as having already been =
escaped (rare).

Likewise, I know you have examples that say "SCRIPT_FILENAME" is safe by =
default (I kind of disagree)... it would still be advisable to encode =
them, even if they are being included in the HTML... personally I would =
not have any variables marked as safe by default (with the single =
exception of strings that are defined in the PHP code itself).

Craig






On 30 Jul 2015, at 13:47, Xinchen Hui <laruence@php.net> wrote:

> Hey:
>=20
> On Thu, Jul 30, 2015 at 8:14 PM, 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 ?
> yes, it is https://github.com/laruence/php-taint
>=20
> Anyway, I was too busy so I didn't make it supports PHP-5.6, I was
> hoping someone could help(it supports 5.5 now).
>=20
> it is a complex extension, and using tricky way to keep taint infos
>=20
> anyway, with PHP7's new zend_string, and string flags, the
> implementation will become easier.
>=20
> I have a plan to make it supports PHP7..
>=20
> thanks
>>=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:
>>=20
>>> 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.
>>>>>=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
>>>> --
>>>> 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
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>=20
>>>=20
>>>=20
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>=20
>>>=20
>=20
>=20
>=20
> --=20
> Xinchen Hui
> @Laruence
> http://www.laruence.com/