Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87667
Return-Path: <dennis@birkholz.biz>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 67060 invoked from network); 6 Aug 2015 11:47:14 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 6 Aug 2015 11:47:14 -0000
Authentication-Results: pb1.pair.com smtp.mail=dennis@birkholz.biz; spf=unknown; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=dennis@birkholz.biz; sender-id=unknown
Received-SPF: unknown (pb1.pair.com: domain birkholz.biz does not designate 144.76.185.252 as permitted sender)
X-PHP-List-Original-Sender: dennis@birkholz.biz
X-Host-Fingerprint: 144.76.185.252 mx01.nexxes.net  
Received: from [144.76.185.252] ([144.76.185.252:45201] helo=mx01.nexxes.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 2C/10-00122-04943C55 for <internals@lists.php.net>; Thu, 06 Aug 2015 07:47:13 -0400
Received: from [137.226.183.192] (ip3192.saw.rwth-aachen.de [137.226.183.192])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: db220660-p0g-1@packages.nexxes.net)
	by mx01.nexxes.net (Postfix) with ESMTPSA id ED3D848246D;
	Thu,  6 Aug 2015 13:47:08 +0200 (CEST)
To: Matt Tait <matt.tait@gmail.com>, Anthony Ferrara <ircmaxell@gmail.com>,
 Julien Pauli <jpauli@php.net>
References: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com>
 <CAMUwpuTJKO+JCWgiVMYRxGDbj1qdhR3Dvoho004KUh_MJoZD4g@mail.gmail.com>
 <CAAyV7nExkQtPd3Z0hdYp_+iF8ATsLu0itBrXCQX0zntr9y4eCA@mail.gmail.com>
 <CAEZfaM5kaMLv9y7T0C9E2Xi=AUuHwAFosjd8wGf6QQ120Pi46Q@mail.gmail.com>
 <CAAyV7nFsqNkbQwCd85p3uAxY4RrPemnqUYktcuT1Xmg50xfdWQ@mail.gmail.com>
 <CAEZfaM6jF=iW2Cc=kNxyFZ4B-HES9aH9ywNWzRXvXOx++06Cag@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <55C3493C.9060200@birkholz.biz>
Date: Thu, 6 Aug 2015 13:47:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAEZfaM6jF=iW2Cc=kNxyFZ4B-HES9aH9ywNWzRXvXOx++06Cag@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: dennis@birkholz.biz (Dennis Birkholz)

Hi Matt,

Am 06.08.2015 um 05:46 schrieb Matt Tait:
> With regards to the fact that not all SQL queries are directly
> parameterizable, this is true. Structural parts of a query, such as table
> names, column names and complex conditions are hard to parameterize with
> "vanilla" prepared statements, and many developers like to abstract some of
> these structural parts of a SQL query into config files, and append
> additional conditional constraints into the query at runtime based on user
> input.
> 
> This feature addresses this head on. So long as the structural parts of the
> prepared statement -- that is, table names, database names and column names
> -- are not themselves attacker-controlled (I can't think of a valid reason
> whey they would be), this feature is happy for developers to concatenate
> them into a query string. For example, the following is not detected by the
> feature as dangerous, because the query (whilst dynamically constructed) is
> the linear concatenation of string literals, and so is a safeconst.

and how exactly do you guarantee the structural part from a
configuration is not attacker-controlled? The config may come from a
json file, from a database, from APCu, etc. and may have been
inserted/generated previously from unsafe user input. If I understand
you right, these parts will not be tainted and thus will give a wrong
feeling of safety to the unskilled/unknowing programmer. Or did I miss
that part in the RFC?

Greets
Dennis