Bug #47802 [Opn->Csd]: PDO_MYSQL doesn't use the charset parameter

Edit report at https://bugs.php.net/bug.php?id=47802&edit=1 ID: 47802 Updated by: johannes@php.net Reported by: disbursement at dublin dot com Summary: PDO_MYSQL doesn't use the charset parameter -Status: Open +Status: Closed Type: Bug Package: MySQL related Operating System: all PHP Version: 5.2.9 -Assigned To: +Assigned To: mysql Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: ------------------------------------------------------------------------ [2011-04-19 11:38:35] johannes@php.net You can write secure code - if you are using a supported encoding (iso-8859-1/latin1, utf-8, ...) ------------------------------------------------------------------------ [2011-04-19 01:58:25] ircmaxell at gmail dot com I won't argue the decision, but I'd like to clarify one point. Right now, in 5.2.x (and <=5.3.5) it's impossible to write a secure query using PDO::quote. So if you use another character set, it would automatically make all code vulnerable to SQL Injection (with no built-in method to fix it). So that leaves existing the code 3 options: Switch to MySQLi, Implement their own quoting mechanism, or switch to prepared statements (the best solution). But as it stands, the API does not deliver its promise. Just an observation... ------------------------------------------------------------------------ [2011-04-19 01:07:20] johannes@php.net If a developer shots himself it is noting we can prevent. Tis does not justify a security release of PHP as the only one who can exploit this is the one writing code ... This should however be made clear in the documentation: Executing SET NAMES doesn't tell anything to the client library (libmysql / mysqlnd used by PHP) so they can't do proper encoding. Therefore only Latin 1, Utf-8 and other encodings using lower 7 bits in an ASCII compatible way can be used safely. For other encodings the mentioned option, introduced later in 5.3.6 should be used. ------------------------------------------------------------------------ [2011-04-18 22:38:48] colder@php.net Re-opening because of 5_2 backport request by some user. ------------------------------------------------------------------------ [2011-04-18 22:34:03] ircmaxell at gmail dot com Re-opening this as it has security implications for 5.2.x. It should be backported and re-released as a security fix for 5.2.x. As it stands now, PDO::quote() does not protect against security vulnerabilities without the ability to set the character set in the C api. 5.3.6 closes this hole when supplied with the optional charset parameter (by appropriately setting the character set). However this will need to be expressed in the documentation (I will file another issue on this topic). Proof Of Concept Code: $dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK'; $pdo = new PDO($dsn, $user, $pass); $pdo->exec('SET NAMES GBK'); $string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*'; $sql = "SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE ".$pdo->quote($string).";"; $stmt = $pdo->query($sql); var_dump($stmt->rowCount()); Expected: int(0) Actual: the number of tables on the server ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=47802 -- Edit this bug report at https://bugs.php.net/bug.php?id=47802&edit=1