Edit report at https://bugs.php.net/bug.php?id=47802&edit=1

 ID:                 47802
 Updated by:         johan...@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] johan...@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] johan...@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] col...@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

Reply via email to