Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87407
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: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAFWS2+FG-Ed_G4KH7o_SOxVgTCuLmpB8=WBkL47z9+v9sTquEA@mail.gmail.com>
Date: Thu, 30 Jul 2015 16:38:04 +0100
Cc: Lester Caine <lester@lsces.co.uk>,
 internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <617E0E34-E407-434F-A441-3452166E89B7@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> <CAFWS2+FG-Ed_G4KH7o_SOxVgTCuLmpB8=WBkL47z9+v9sTquEA@mail.gmail.com>
To: Ronald Chmara <ronabop@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: craig@craigfrancis.co.uk (Craig Francis)

On 30 Jul 2015, at 16:26, Ronald Chmara <ronabop@gmail.com> wrote:

> Perhaps I have missed something in this discussion


I think you have... my email from a couple of weeks ago was ignored... =
so I replied to Matt's suggestion (which is similar, but different).

Please, just spend a few minutes reading my suggestion, it has =
absolutely nothing todo with breaking applications:

   http://news.php.net/php.internals/87207

   https://bugs.php.net/bug.php?id=3D69886

And yes, I do have a bypass_the_nerfing function (well, a function to =
say the variable has already been escaped)... but the idea is that it's =
ever so slightly harder to use than the related escaping functions, and =
rarely needed.






On 30 Jul 2015, at 16:26, Ronald Chmara <ronabop@gmail.com> wrote:

> Perhaps I have missed something in this discussion where such a change =
to PHP does not break every single application that is supposed to pass =
raw, user submitted, SQL *without* getting prepared/nerfed, or warned =
about, by intentional application design.
>=20
> If we're just limiting the nerfing for submitted GPC variables (since =
PHP is used a lot for web applications).... we still have a non-trivial =
number of those installed applications which require raw, user created, =
unescaped SQL, passing through to function as designed.
>=20
> I am thinking of the class of applications like phpMyAdmin, as well as =
the the millions of other database utility scripts, application install =
scripts, (etc.) out there that perform similar tasks, that need to pass =
raw SQL, as crafted by users, without preparation, intentionally.
>=20
> Of course, we could just add a "bypass_the_nerfing()" function, and =
such a function could then possibly see widespread adoption, everywhere, =
rendering the entire exercise moot.