Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60894
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 141.146.126.227 as permitted sender)
Message-ID: <4FE0F301.70808@oracle.com>
Date: Tue, 19 Jun 2012 14:45:37 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAAyV7nFciZcsL+AW9W4GbhM+PhM3RhWOJ7G0iBQsEHfSWO2QmA@mail.gmail.com> <4FDB5604.5000704@oracle.com> <4FDB62C2.6090702@oracle.com> <4FDC3396.10406@phpdoc.de>
In-Reply-To: <4FDC3396.10406@phpdoc.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default
 for PDO_Mysql
From: christopher.jones@oracle.com (Christopher Jones)



On 06/16/2012 12:19 AM, Ulf Wendel wrote:
> Am 15.06.2012 18:28, schrieb Christopher Jones:
>
>> On 06/15/2012 08:34 AM, Ulf Wendel wrote:
>>> As long as client-side escaping is done properly, there is no
>>> practical difference between the [client vs server -prepare]
>>> approaches.
>>
>> The big problem with this line of reasoning is that the client must
>> know exactly the same dialect of SQL/XQUERY/whatever that the server
>> does. Since we can't predict the future, and so a new DB might
>
> Plain wrong. If client does not mess up on type and charsets there is no practical difference between the security of properly done client side escaping and server-side escaping. No matter if the subject of escaping is a fairy tale on goofy or any other
> string that happens to look like any other human invented format, e.g. SQL.
>
> Ulf
>

We should take this offline - I can see cases where I'd strongly disagree.

Chris

-- 
christopher.jones@oracle.com
http://twitter.com/#!/ghrd