- First commit to issue fork.
- Merge request !11574Disable ATTR_EMULATE_PREPARES to see how many tests it breaks → (Open) created by prudloff
Postgres PDO Driver uses native statement preparation by default. PDO MySQL uses emulated prepares by default. Native prepares are much more robust against SQL injection, so should be used if at all possible.
As a side effect, MySQL native prepares only support preparing one SQL statement at a time.
In Drupal 6 and below a sql injection vulnerability/attack was limited in what it could achieve by the surrounding statement. For example, if there were a select statement it could only do selects and maybe union data, but it couldn't be closed with a ; and then have an update executed. An update of one table could only update that one table.
Drupal 7, with adopting PDO, makes it possible to close off the first query and execute a second query. This makes a sql injection vulnerability a much riskier thing.
### Risks/benefits:
* Benefit: not executing multiple queries.
* Risk/Benefit (?): statement preparation (including security related elements) is moved to mysql instead of php. I don't know how that might impact any code we have related to security. It seems reasonable to me to trust the mysql escaping as much as the PHPPDO escaping.
* Risk: validation of statements, including exceptions about a column or table that is missing, will be thrown during prepare instead of execute. We may have some code that relies on
* Risk: additional TCP round trip time when doing a prepared statement query. This could add up in cloud settings where the connection to the database server takes longer.
### Some research:
* the original thread that pointed me to this option
* A pretty solid stack overflow thread on php-pdo-mysql and impact
* php documentation on the attribute - pretty limited
I'm purposefully filing this in public. Even though it is related to security it's about hardening. This issue doesn't expose any vulnerabilities in Drupal and a change like this deserves broad review.
Needs work
11.0 🔥
database system
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
It may affect performance, and thus requires in-depth technical reviews and profiling.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.