That sounds like something that would require both a deprecation and an RFC
for the change then, even if the actual change in the source is small.
It still may be worth exploring, since this surely gives a large number of
people false confidence in protection against injection attacks, as nearly
every available tutorial on using PDO in PHP declares that simply using
prepared statements protects you from injection attacks.
On Sun, Jul 18, 2021 at 12:47 AM AllenJB <php.li...@allenjb.me.uk> wrote:
>
> 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",
> ];
>
>
>
