Consider disabling PDO emulated query parser by default
まだ誰も着手していません。
- 主要言語
- C
- スター
- 40.4k
- フォーク
- 8.1k
- 平均マージ
- 2日 13時間
- マージ済み PR(30日)
- 96
説明
Description
This is a copy of https://github.com/doctrine/dbal/issues/7146 opened at doctrine/dbal, as the same change can be considered in php-src as well.
I've been linked to a quite interesting article regarding possible SQL injection when using PDO: https://slcyber.io/assetnote-security-research-center/a-novel-technique-for-sql-injection-in-pdos-prepared-statements/. It describes a method that confuses the PDO emulated query parser into something that shouldn't happen with bound parameters, which in certain scenarios can be used to execute SQL injection.
This brings the question: why should we even want to use this emulation? From my understanding this is an artifact from the past, where the common consensus was that it would benefit performance as prepared statements would skip the query cache with older MySQL versions. But is that still relevant today?
Which is why I'd like to open a discussion: should pdo_mysql consider setting the PDO::ATTR_EMULATE_PREPARES to false by default?
Proof of concept with doctrine:
$address = $request->query->getString('q'); // http://somehost/some/page?q=?%00
dd($this
->getEntityManager()
->getConnection()
->executeStatement("SELECT * FROM address WHERE address1 LIKE '%$address%' AND city = ?", ['enschede'])
);
Which throws SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens, which is solved by adding ->option(PDO::ATTR_EMULATE_PREPARES, false) to the dbal driver configuration.
PHP Version
PHP 8.4.12 (cli) (built: Sep 7 2025 14:04:14) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.12, Copyright (c) Zend Technologies
with Zend OPcache v8.4.12, Copyright (c), by Zend Technologies
with Xdebug v3.4.5, Copyright (c) 2002-2025, by Derick Rethans
Operating System
No response
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
pdo_mysql の実装と PDO::ATTR_EMULATE_PREPARES の扱いから始めます。リンクされたセキュリティ調査と既存のテストまたはデフォルト値を確認し、完了とみなすべき動作と回帰テストのカバレッジを決定する前に、互換性とパフォーマンスへの影響を明らかにします。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- mysql, php
- 領域
- databases, security
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100