Check PDO prepared statements #1859
Description
It turns out that PDO prepared statements are (by default) not actually prepared statements, but are rather parsed by some internal PDO prepared statement parser. And of course, this PDO parser does not implement a full SQL parser, which opens up PDO prepared statements too all kinds of injection attacks, like for example described here: https://slcyber.io/assetnote-security-research-center/a-novel-technique-for-sql-injection-in-pdos-prepared-statements/
Fortunately, there is a simple fix: set PDO::ATTR_EMULATE_PREPARES to false, which disables this ridiculous behaviour and reverts back to the behaviour you'd expect: let the database engine handle prepared statements.
Please check if we indeed disable this setting in EB, and if not, add the setting. I expect us not to depend on weird PDO behaviour, so I would hope that changing this setting won't have any impact (famous last words...).
Note that the PDP docs say this:
Whether enable or disable emulation of prepared statements. Some drivers do not support prepared statements natively or have limited support for them. If set to true PDO will always emulate prepared statements, otherwise PDO will attempt to use native prepared statements. In case the driver cannot successfully prepare the current query, PDO will always fall back to emulating the prepared statement.
(https://www.php.net/manual/en/pdo.setattribute.php)
The latter part of this worries me. Does PHP emit a warning when it falls back to emulating the prepared statement? What exactly does it mean that the MySQL driver has "limited support" for prepared statements? What kind of statements would fail preparing by the driver?