> Are there documented SQL injection opportunities when using emulated
prepares? I'm not aware of any.
This was from my reading of the actual source, which of course may be
flawed. It appeared that if emulated prepares were used the values were
escaped and then passed as strings as part of the query, the same as if it
had been concatenated and wrapped in real_escape_string. I hadn't gone too
far in actually debugging it yet to find out how it behaved under different
circumstances as I was still trying to figure out how "small" of a change
this was from the perspective of internals.
On Sun, Jul 18, 2021 at 3:38 PM Benjamin Morel <benjamin.mo...@gmail.com>
wrote:
> 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",
>> ];
>>
>
> This, and do note that from a performance point of view, disabling
> emulated prepares is not innocuous : most of the time, you effectively send
> twice as many queries to the database : one prepare, one execute.
> There is a *small* performance improvement in using prepared statements
> if you're executing the same statement many times; but in all other cases,
> you're spending twice as much time waiting for the database.
>
> Are there documented SQL injection opportunities when using emulated
> prepares? I'm not aware of any.
>
> — Benjamin
>
