Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87446
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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>
	<617E0E34-E407-434F-A441-3452166E89B7@craigfrancis.co.uk>
Date: Fri, 31 Jul 2015 09:40:36 -0700
Message-ID: <CAFWS2+GVtTp7n+7LB78PNccEmH4QU-XtWd_BOxAAFJUp7eoFnQ@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: Lester Caine <lester@lsces.co.uk>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01229758b6363b051c2e7ae3
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: ronabop@gmail.com (Ronald Chmara)

--089e01229758b6363b051c2e7ae3
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 30, 2015 at 8:38 AM, Craig Francis <craig@craigfrancis.co.uk>
wrote:

> 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=69886


The RFC and bug report both make an erroneous assumption that unescaped GPC
input is wrong.

I was addressing some cases where it is the correct, intended, behavior.

WRT "breaking":
Application stacks which go from zero E_NOTICE warnings, to hundreds or
thousands of them a second or day, is (admittedly) poorly phrased as
"breaking". It is a possible side effect of the proposed solutiions. I have
worked in very stingent environments where an unapproved E_NOTICE is
considered a ship-stop break, but I did not explicitly explain that. Such
environments would require re-writes of all SQL that throws an E_NOTICE, or
a per-line exception review and approval process, or disabling/not enabling
the checking.


> 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.


"Rarely" is subjective at this point, a quanyifyable sampling of some kind
could be more meaningful. (How rare?)

Based on *my* purely anecdotal experience, in the last X years of using PHP
I have have frequently encountered situations where passing through
engine-unescaped text strings, to SQL, is desired for some reason, in
nearly every environment. I mentioned one use case that I thought might be
relevant to a large number of users, there are others.

Off the top of my head, some use cases I have dealt with relevant to this
discussion, that should be considered (even if they're discarded as
trivial):
1. Administrator has a web application that is supposed to allow them
access functionally equivalent to a direct connection to a database.
2. Overhead of using the engine escaping technique (setup connection(if not
done yet), send text to escape at network speed, recieve escaped text at
network speed) was considered too much of an additional performance hit.
3. Text needed to have a generic, user written, escaping library/function
to handle multiple destinations (think 5 different data storage systems,
all with different escaping rules, some without connection based escaping).
4. Text being supplied was coming from a pre-cleaned, trusted, source, even
though the variable was GPC, (example: it was a GET string assembled by a
batch job that was pulling from another database)

I'm sure there are many more.

Basing language decisions on personal perceptions of "rarely" and
"frequently" is not a good practice, but ensuring that we are covering
multiple use-cases is. Discussing the use cases doesn't mean I think the
idea is without merit.

-Ronabop

--089e01229758b6363b051c2e7ae3--