この脆弱性は本家にはレポートしてあるのですが簡単な1行パッチなのにまだCVSにさえ適用されていません。詳しく解説したつもりなのですがシングルバイト圏の開発者には理解が難しい(?)か私の説明が悪かった(?)のかも知れません。とりあえず「作業中」との旨のメールが帰って来ていますが遅すぎなので特に影響が大きいと思われる日本のサイト向けとして問題の概要と対処方法を書いておきます。
文字エンコーディングを利用したSQLインジェクションに詳しい方ならどのような条件でSQLインジェクションが可能になるか簡単に分かります。addslashesやstr_replaceによるエスケープが危険であることは広く知られている既知の問題といえると思います。英語で記述されたブログ等にもエンコーディングとエスケープの問題を取り扱ってるページもあります。あまり長期間放置していると近い将来悪用される危険性があります。
このパッチを有効に利用するには使用しているPostgreSQLサーバのバージョンに関わらず、PostgreSQL 8.1.4以降のlibpqを利用してPHPのPostgreSQLモジュールをビルドする必要があります。
# これはPostgreSQL 8.1.4以降のlibpqを利用しなければならいない
# 点はPEAR DB/PHPに限らず、PostgreSQLアプリケーション全般として
# いえます。
[yohgaki@dev pear]$ cat DB/DB/DB_pgsql.php.patch
Index: pgsql.php
===================================================================
RCS file: /repository/pear/DB/DB/pgsql.php,v
retrieving revision 1.129
diff -u -r1.129 pgsql.php
— pgsql.php 10 Jun 2005 14:31:45 -0000 1.129
+++ pgsql.php 17 Aug 2006 09:34:16 -0000
@@ -531,7 +531,7 @@
*/
function escapeSimple($str)
{
– return str_replace(“‘”, “””, str_replace(‘\\’, ‘\\\\’, $str));
+ return pg_escape_string($str);
}// }}}
他のDBアクセス抽象化ライブラリにも同じ脆弱性がある可能性が高いと思われます。パッチ自体は簡単なのでDBアクセスアクセスの抽象化ライブラリを利用されている方は一度調べた方が良いと思います。
Leave a Comment