Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44747C34.7080006@emini.dk>
Date: Wed, 24 May 2006 17:31:00 +0200
Organization: Emini A/S
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: "D. Dante Lorenso" <dante@vocalspace.com>
Cc: PHPdev <internals@lists.php.net>
References: <4474624D.90304@vocalspace.com>
In-Reply-To: <4474624D.90304@vocalspace.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Is PostgreSQL 8.1.3--->8.1.4 necessary for 'properly'
	escaped coders?
From: edink@emini.dk (Edin Kadribasic)

I just read the documentation on PostgreSQL site and it seems that you 
should be safe as long as you are escaping ' with sql standard '' and 
not addslashes() way \'. Native libpq used in PDO and pg_escape_string() 
escape ' properly.

Edin


D. Dante Lorenso wrote:
> All,
> I use PostgreSQL 8.1.3 extensively.  Currently all my PHP 5.1.4 code is 
> using the pgsql extension to connect.  My newer development code is 
> connecting through the newer PDO/pgsql extension. 
> Is the PostgreSQL 8.1.4 SQL injection bug fix necessary if I've been 
> well behaved by passing *all* sql values through either of these 
> escaping functions?:
> 
>    * pgsql: pg_escape_string(...)
>    * PDO: bindValue(..., ..., ...)
> 
> A question similar was recently posted over in general, but I didn't see 
> any response and a reply suggested we ask internals. 
> See the recent Slashdot post:
> 
> ======================================================================
> Developers: PostgreSQL 8.1.4 Released to Plug Injection Hole
> ======================================================================
> Posted by [1]ScuttleMonkey on Tuesday May 23, @09:42PM from the
> good-little-dutch-boy dept.
> alurkar writes to tell us that PostgreSQL released version 8.1.4 today
> in order to combat a security flaw allowing a [2]SQL injection attack.
>  From the article: "The vulnerability affects PostgreSQL servers
> exposed to untrusted input, such as input coming from Web forms, in
> conjunction with multi-byte encodings like (Shift-JIS (SJIS), 8-bit
> Unicode Transformation Format (UTF-8), 16-bit Unicode Transformation
> Format (UTF-16), and BIG5. In particular, Berkus says that
> applications using 'ad-hoc methods to "escape" strings going into the
> database, such as regexes, or PHP3's addslashes() and magic_quotes'
> are particularly unsafe. 'Since these bypass database-specific code
> for safe handling of strings, many such applications will need to be
> re-written to become secure.'"
> 
> [1] http://slashdot.org/~ScuttleMonkey/
> [2] http://www.newsforge.com/article.pl?sid=06/05/23/2141246
> [3] http://developers.slashdot.org/developers/06/05/23/2228225.shtml
> [4] http://developers.slashdot.org/developers/06/05/23/2228225.shtml
> [5] 
> http://developers.slashdot.org/article.pl?sid=06/05/23/2228225&threshold=-1
> [6] http://developers.slashdot.org/
> 
> Dante
>