[PHP-users 32375] Re: ＰＨＰを使ってのPostgresqlについて

[Yasuo Ohgaki]

大垣です。

KOYAMA Tetsuji さんは書きました:
> 小山です。
> 
> On 7/4/07, Yasuo Ohgaki <yohgaki ＠ ohgaki.net> wrote:
>> PEAR_DBもPostgreSQLのプリペアードステートメントはサポートしてい
>> なかったと思うのでescapeメソッドを使う方法が最も自然なコーディング
>> だと思います。PEAR_DBは使わないのでもしかしたらプリペアードクエリ
>> を上手に使う方法もあるのかも知れません。
> 
> PEAR::DB は、pg_prepare ができる前から独自のプリペアードステートメント
> エミュレーションを持っているので、それを使えば効率はともかく安全に
> SQL を発行することができます。
> 
> $db =& DB::connect($dsn);
> $result = $db->query('SELECT * FROM table WHERE id=?', array($id));
> 
> という感じです。
> 

Zend_DBも同じようにエミュレーションになっています。PEAR_DBの場合、
pg_escape_stringの代わりにstr_replaceが使われていました。このため、
SJIS、EUCがクライアントエンコーディングの場合、文字エンコーディング
を利用したSQLインジェクションが可能になっていました。本来はこれで安
全になるようなコードになっているべきですが今年初めまではSJIS, EUCを
利用しているユーザは危険な状態でした...

PEARのリリース 1.7.8（今年の2月頃リリースかな?）からpg_escape_string
を使うようになったようです。

# コードのコメントを見ると何故pg_escape_stringに新しいシグニチャが
# 追加されたのかよく理解されていないような... 去年の初めにPEAR_DB
# のメンテナには一報入れて、なぜ単純置換が問題か簡単に説明してい
# たのですが... MySQLのコードも似たような状況だったと思っています
# が詳しくは把握していません。

PEAR_DBの例は極端かも知れませんが、自分でライブラリのコードを見て安
全性を確認できるようになるためにも「SQLインジェクション対策はプリペ
アードステートメントで十分」と言いたいところですが、そうも行かない
ケースも見かけます。

さすがにZend FWはリリース1.0になったので対処しているとは思いますが
初期の開発版リリースはOracleのDBドライバはエスケープが全く無しに
なっていました。MS SQL Server、OCIには文字列エスケープ関数が無かっ
たので安全に使えるコードなっているのかな?と不安に思っていたりします...

-- 
Yasuo Ohgaki : yohgaki ＠ ohgaki.net : http://www.ohgaki.net/