Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78123
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <1413481197.3616.0.camel@daevel.net>
References: <CAAyV7nFciZcsL+AW9W4GbhM+PhM3RhWOJ7G0iBQsEHfSWO2QmA@mail.gmail.com> <CAH-PCH6jVcXNtyySeY4EJZt2sQqhXFV=acO_x3HJb2f7WKtMPQ@mail.gmail.com> <543FE883.2070401@lerdorf.com> <CAH-PCH65qUuZvzu6q6BF80O-peowgB2K9nAWDznEfgOTgcj7eg@mail.gmail.com> <1413481197.3616.0.camel@daevel.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Thu, 16 Oct 2014 23:59:22 +0100
To: PHP Internals <internals@lists.php.net>
Message-ID: <FAA8ADB0-742E-480C-8559-98BF9CB4A176@gmail.com>
Subject: Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
From: rowan.collins@gmail.com (Rowan Collins)

On 16 October 2014 18:39:57 GMT+01:00, Olivier Bonvalet <php-dev.list@daevel.net> wrote:
>Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
>> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf <rasmus@lerdorf.com>
>wrote:
>> 
>> > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
>> > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara
><ircmaxell@gmail.com>
>> > > wrote:
>> > >
>> > >> Hello all,
>> > >>
>> > >> I raised this topic on list over a year ago (
>> > >> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It
>was
>> > >> determined that it wasn't time yet to disable prepared statement
>> > >> emulation for MySQL yet. However, Rasmus did mention that it was
>a
>> > >> possibility for 5.4 (
>> > >> http://marc.info/?l=php-internals&m=130418875017027&w=2 ). Since
>that
>> > >> ship has sailed, I submitted a pull request for trunk to change
>the
>> > >> default value of prepared statement emulation for MySQL.
>> > >>
>> > >> https://github.com/php/php-src/pull/108
>> > >>
>> > >> https://bugs.php.net/bug.php?id=54638
>> > >>
>> > >> Does this need to be an RFC (should I draft one)? Or can it just
>be
>> > >> pulled as-is?
>> > >>
>> > >> Thanks,
>> > >>
>> > >> Anthony
>> > >>
>> > >> --
>> > >> PHP Internals - PHP Runtime Development Mailing List
>> > >> To unsubscribe, visit: http://www.php.net/unsub.php
>> > >>
>> > >>
>> > > hi,
>> > >
>> > > do we want to change the default for this in PHP7?
>> >
>> > Honestly, I am not sure about this anymore. There is a significant
>> > performance benefit in doing client-side prepares. Last year I
>attempted
>> > to switch to server-side prepares on Etsy's production servers but
>it
>> > added 30-40ms of page latency because of the extra round trips. And
>yes,
>> > we were doing too many queries, but I fear if we change this
>default
>> > people won't understand where this slowdown is coming from.
>> >
>> > Of course, in some rare cases using server-side prepares might
>speed
>> > things up because of prepared statement caching in the server, but
>I
>> > have yet to see a case where that caching outweighs the extra tcp
>> > roundtrip overhead.
>> >
>> > I do agree that the default should probably be server-side since it
>is
>> > the least surprising. We just need to make it very very clear in
>the
>> > upgrade doc that this change will likely slow down peoples' apps
>and
>> > show them how to turn client-side prepares back on.
>> >
>> > -Rasmus
>> >
>> 
>> I don't think we should remove the option, just change the defaults,
>and
>> most people would be fine switching back to the emulation, but it
>should be
>> their conscious decision imo.
>> Currently many people aren't aware that they are using client side
>> prepares, and they are pretty much ignore the fact, that they can be
>> exposed to sql injections (for example via using mismatching client
>and
>> server encodings or not properly quoting the identifiers:
>> http://www.codeyellow.nl/identifier-sqli.html because they think that
>> server side prepared statements would be immune to this kind of
>problems).
>> I think it would be better to change the default in a major version,
>if the
>> tradeoff is performance vs security, and if they think that they are
>okay
>> with the emulation, they can change it back.
>> 
>> 
>> ps:
>> don't forget that some/many of our users are still using php on a
>single
>> server setup, where the mysql connection is done through a unix
>socket
>> instead of the network stack, so the roundtrip there will be even
>less
>> noticable, and usually those are the kind of users, who need safe
>defaults
>> because they can't afford to be aware or change settings/code for
>their
>> apps.
>> 
>
>Hi,
>
>for me there is two usage of prepared statements : 
>#1 : safely handle variables
>#2 : performance in batch traitments
>
>The first one want emulated prepared statments and the second need true
>prepared.

Surely this is the other way around? Emulation has imperfect security, because it is basically a smarter version of "magic quotes", e.g. the character encoding mismatch already mentioned. It's only advantage over real prepares is performance, if network latency is a significant factor.