Обсуждение: 8.1.4: Who says "PHP deprecated addslashes since 4.0"?
The PostgreSQL-8.1.4 release documentation says we should be using PostgreSQL-supplied string escaping routines, not "homebrew" methods. No argument from me on this. But in the "User Guide to the 8.1.4 Security Update", it says: | An example of an application at risk is a PHP program that uses | addslashes() or magic_quotes. We note that these tools have been deprecated | by the PHP group since version 4.0. Can anyone provide a source for the statement? It's odd, since PHP-4.0 was released on 2000-05-22, shortly after PostgreSQL-7.0, and the PQescapeString() function wasn't even added to libpq until PostgreSQL-7.2 almost 2 years later. The current PHP reference manual doesn't discourage use of addslashes() for database input. I agree with you - this is wrong - but where did the "We note... deprecated by the PHP group since version 4.0" line come from?
ljb <ljb220@mindspring.com> writes: > | addslashes() or magic_quotes. We note that these tools have been deprecated > | by the PHP group since version 4.0. > Can anyone provide a source for the statement? I'm not going to put words in Josh's mouth about where he got that from, but anyone who reads all of the comments at http://us3.php.net/manual/en/function.addslashes.php ought to come away suitably unimpressed with the security of that function. regards, tom lane
tgl@sss.pgh.pa.us wrote: > ljb <ljb220@mindspring.com> writes: >> | addslashes() or magic_quotes. We note that these tools have been deprecated >> | by the PHP group since version 4.0. > >> Can anyone provide a source for the statement? > > I'm not going to put words in Josh's mouth about where he got that from, > but anyone who reads all of the comments at > http://us3.php.net/manual/en/function.addslashes.php > ought to come away suitably unimpressed with the security of that > function. Yes, sorry, I did see those comments, although I don't think they are from the PHP group themselves. But I missed the statement on the pg_escape_string manual page saying "use of this function is recommended instead of addslashes()". I still think "since version 4.0" is wrong.
ljb wrote: > tgl@sss.pgh.pa.us wrote: > >> ljb <ljb220@mindspring.com> writes: >> >>> | addslashes() or magic_quotes. We note that these tools have been deprecated >>> | by the PHP group since version 4.0. >>> >>> Can anyone provide a source for the statement? >>> >> I'm not going to put words in Josh's mouth about where he got that from, >> but anyone who reads all of the comments at >> http://us3.php.net/manual/en/function.addslashes.php >> ought to come away suitably unimpressed with the security of that >> function. >> > > Yes, sorry, I did see those comments, although I don't think they are from > the PHP group themselves. But I missed the statement on the pg_escape_string > manual page saying "use of this function is recommended instead of > addslashes()". I still think "since version 4.0" is wrong. > Better yet, use PEAR::DB or some other db abstraction package that will handle all of this for you.
On Fri, 2006-05-26 at 08:58, Erik Jones wrote: > ljb wrote: > > tgl@sss.pgh.pa.us wrote: > > > >> ljb <ljb220@mindspring.com> writes: > >> > >>> | addslashes() or magic_quotes. We note that these tools have been deprecated > >>> | by the PHP group since version 4.0. > >>> > >>> Can anyone provide a source for the statement? > >>> > >> I'm not going to put words in Josh's mouth about where he got that from, > >> but anyone who reads all of the comments at > >> http://us3.php.net/manual/en/function.addslashes.php > >> ought to come away suitably unimpressed with the security of that > >> function. > >> > > > > Yes, sorry, I did see those comments, although I don't think they are from > > the PHP group themselves. But I missed the statement on the pg_escape_string > > manual page saying "use of this function is recommended instead of > > addslashes()". I still think "since version 4.0" is wrong. > > > Better yet, use PEAR::DB or some other db abstraction package that will > handle all of this for you. Or, if you're going to use the native pgsql interface, you can always use prepared queries. http://www.php.net/manual/en/function.pg-prepare.php Actually, other than still not having error numbers (just the error messages, seems like "priority inversion" to me, btw) the pgsql interface in php is quite robust. You can even run async queries with it.