php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #62978 pg_select() and similar are vulnerable to SQL injection via identifier
Submitted: 2012-08-30 22:58 UTC Modified: 2015-04-08 09:36 UTC
From: slokunshialgo at gmail dot com Assigned: yohgaki (profile)
Status: Closed Package: PostgreSQL related
PHP Version: 5.3 - master OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: slokunshialgo at gmail dot com
New email:
PHP Version: OS:

 

 [2012-08-30 22:58 UTC] slokunshialgo at gmail dot com 
Description:
------------
---
From manual page: http://www.php.net/function.pg-select#refsect1-function.pg-select-examples
---
The one example given passes $_POST directly to pg_select as a list of parameters to select on. There are 2 major issues with this:

1) It doesn't show the actual parameters being passed, making the example difficult to understand
2) Using end-user-supplied values like this is a perfect vector for SQL injection, and as such as a huge security risk.

While #1 is a concern, #2 is a larger one, since newer programmers seeing it will think that's good practice, and start putting such security issues into their own code.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-29 20:36 UTC] yohgaki@php.net
-Status: Open +Status: Analyzed -Type: Documentation Problem +Type: Security -Package: Documentation problem +Package: PostgreSQL related -Assigned To: +Assigned To: yohgaki -Private report: No +Private report: Yes
 [2013-06-29 20:36 UTC] yohgaki@php.net 
This is the way it is supposed to use. pg_select() and similar functions should 
automatically escape string vars, and they do. 

pg_select($db, 't1',['str'=>"It's a string"]);
produces
LOG:  文: SELECT * FROM t1 WHERE str='It''s a string';
Note that string is properly escaped.

However, they don't escape identifier. This should be fixed.
 [2013-06-29 20:36 UTC] yohgaki@php.net 
This is the way it is supposed to use. pg_select() and similar functions should 
automatically escape string vars, and they do. 

pg_select($db, 't1',['str'=>"It's a string"]);
produces
LOG:  文: SELECT * FROM t1 WHERE str='It''s a string';
Note that string is properly escaped.

However, they don't escape identifier. This should be fixed.
 [2013-06-29 20:39 UTC] yohgaki@php.net
-Status: Analyzed +Status: Assigned -Operating System: +Operating System: * -PHP Version: 5.4.6 +PHP Version: 5.3 - master
 [2013-06-29 20:39 UTC] yohgaki@php.net 
I think this problem existed from the beginning. So any version which have 
pg_select()/etc are affected.
 [2013-06-29 20:49 UTC] yohgaki@php.net
-Summary: pg_select() doc example has severe security issues +Summary: pg_select() and similar are vulnerable to SQL injection via identifier
 [2013-06-29 20:49 UTC] yohgaki@php.net 
Changed Summary to descriptive one.
 [2013-06-30 21:30 UTC] yohgaki@php.net 
I've made patch against PHP-5.3

https://github.com/yohgaki/php-src/compare/PHP-5.3-pg_select_fix

It passes tests with PostgreSQL 9.2, but it should be tested with 8.4 or less.
This patch supposed to be able to merge upto master, but not tested yet.
 [2013-08-05 10:01 UTC] yohgaki@php.net
-Status: Assigned +Status: Closed
 [2013-08-05 10:01 UTC] yohgaki@php.net 
Fixed. 

http://git.php.net/?p=php-
src.git;a=commitdiff;h=cb8d1fc7f913085117da109f89a1e5a6cb535c09
 [2013-08-05 10:02 UTC] yohgaki@php.net
-Type: Security +Type: Bug
 [2013-08-05 10:02 UTC] yohgaki@php.net 
This fix is treated as security enhancement, so 5.3 branch won't be fixed.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 14:01:29 2024 UTC