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

[kanonbell]

こんばんは。

> おっしゃる通りプリペアードクエリを利用すればセキュリティ的には全てエスケープ
> するのと同じことなのでプリペアードクエリが利用できる場合はプリペアードクエリ
> で十分です。

それを聞いて安心しました。
バリデーションは必要ですが、実装の負担が随分減るので、私は9割がたPrepared
Statementにしちゃってます。残りの1割はユーザーの入力値を含まない静的なもの。
こんな楽なのにお勧めする人って少ないなあと。
と思ったら。

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

そういえばもう怪談の季節ですねえ。。
文字エンコーディングを利用したってのはこういうののことでしょうか？
SQLインジェクションじゃなくてXSSですけど。
http://www.atmarkit.co.jp/fsecurity/rensai/hoshino10/hoshino01.html

気になって使用しているADOdbのソース見てみましたが、うーん。。
通常のPrepared Statementでは、MSSQLとかだとエミュレーションされてて、
入力値はstr_replaceで普通に置換されてました。mssql_bind使えない
理由でもあるのかしらん。どーなんだろこれ。。

よろしければ、str_replaceだと防げない攻撃方法の手順や、pg_escape_string
のようなエスケープ関数がない場合のエスケープ方法など教えていただけませんか？
上の記事と同様なら、いったんmb_convert_encodingくぐらせるのかな。


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

確かにそうですね。使いやすいライブラリ提供してくださる方々には頭が下がりますが、
ちゃんと確認して使わなきゃダメだなあ。。
通り一遍見てみたけどまったく気づいてませんでしたけれど。