Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27422
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 212.112.227.169 cause and error)
Message-ID: <45A8FF84.7000305@pooteeweet.org>
Date: Sat, 13 Jan 2007 16:49:24 +0100
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Stefan Esser <sesser@hardened-php.net>
Cc: info@ch2o.info,
	"internals@lists.php.net" <internals@lists.php.net>
References: <F1076B95-2D05-4690-AE84-21FC0552F17A@ch2o.info> <45A8FC49.7050909@hardened-php.net>
In-Reply-To: <45A8FC49.7050909@hardened-php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Comments on PHP security
From: mls@pooteeweet.org (Lukas Kahwe Smith)

Stefan Esser wrote:

> While it is true that the PHP script is not subject to SQL injection
> when the application does not build parts of the query based on
> untrusted userinput it is not true that you are not at risk.
> Ever heard of stored procedures? And precisely of SQL injection in
> stored procedures? Prepared statements can do nothing about SQL
> Injection in Stored Procedures. And if you teach people that they only
> should use prepared statements they will NEVER know that it is dangerous
> to put userinput into the query. And aside from that they have never
> learned how to do it correctly if there is ever a situation where they
> have to do it.

Maybe I am missing something. If you are talking about dynamic query 
generation in stored routines, then I would think that people who read 
the advice over dynamic query generation for PHP, that they would 
hopefully also apply those practices to when they are writing/using 
stored routines. Also DBA's in general are not all that fond of dynamic 
query generation in stored routines.

Someone also mentioned that LIMIT parameters cannot be prepared:
"As of MySQL 5.0.7, placeholders can be used for the arguments of the 
LIMIT clause when using prepared statements."

So at least in MySQL this works. I dont know about PostgreSQL or 
Firebird. SQLite does not natively support prepared statements anyways.

Furthermore there is currently no good way in PHP to really reuse 
prepared statements across requests in PHP, as such they help you very 
little in terms of improving performance, unless you reuse the query 
multiple times in a request. As a matter of fact they may even reduce 
performance, because they may generate query plans that are inefficient 
for the given placeholder values. This is because the query plan is 
either optimized for the most general case or the first set of 
placeholder values

Anyways .. we are moving away from PHP here.

regards,
Lukas