Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115460 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 80969 invoked from network); 18 Jul 2021 07:22:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jul 2021 07:22:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 84F531804AA for ; Sun, 18 Jul 2021 00:47:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail.apserver.co.uk (server2.alteredperspective.co.uk [85.119.82.103]) by php-smtp4.php.net (Postfix) with ESMTP for ; Sun, 18 Jul 2021 00:47:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.apserver.co.uk (Postfix) with ESMTP id CBA6D4F4064; Sun, 18 Jul 2021 08:32:38 +0100 (BST) Received: from mail.apserver.co.uk ([127.0.0.1]) by localhost (server2.alteredperspective.co.uk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LbboXe54X4JF; Sun, 18 Jul 2021 08:32:37 +0100 (BST) Received: from [192.168.0.9] (maid-09-b2-v4wan-162707-cust865.vm41.cable.virginm.net [82.44.111.98]) by mail.apserver.co.uk (Postfix) with ESMTPA id 6558A4F4061; Sun, 18 Jul 2021 08:32:37 +0100 (BST) To: Jordan LeDoux , Craig Francis Cc: Marco Pivetta , PHP internals References: Message-ID: Date: Sun, 18 Jul 2021 08:47:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal From: php.lists@allenjb.me.uk (AllenJB) On 18/07/2021 03:41, Jordan LeDoux wrote: > Related to the general topic of injection attacks, I was considering > submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to > FALSE, since this mistakenly can lead people to believe that using prepared > statements with PDO and MySQL protects against injection attacks. In fact, > this is only the case if they create the PDO object with the option > specified as false. I'm not aware however to reasoning for enabling prepare > emulation by default for MySQL. I would assume it's a performance choice, > but how long ago was this choice made and is it worth revisiting? Would > this be something that requires its own RFC? It's a single line change. > > Jordan There's some BC-breaks to be aware of when switching emulated prepares. One example I know of is that when using emulated prepares you can reuse the same placeholder (as in the following example), but with emulated prepares disabled this does not work. $sql = "SELECT * FROM table WHERE column1 LIKE CONCAT('%', :searchValue, '%') OR column2 LIKE CONCAT('%', :searchValue, '%');"; $params = [     "searchValue" => "test", ]; With emulated prepares disabled you have to use: $sql = "SELECT * FROM table WHERE column1 LIKE CONCAT('%', :searchValue, '%') OR column2 LIKE CONCAT('%', :searchValue2, '%');"; $params = [     "searchValue" => "test",     "searchValue2" => "test", ];