http://blog.ohgaki.net/?disp=comments ja-JP http://backend.userland.com/rss 60 Sun, 19 Feb 2006 14:44:06 +0000 石井 [訪問者] c782@http://blog.ohgaki.net/ pg_set_client_encodingを呼ぶのと，SET client_encoding TO をするのは，PostgreSQL 7.4以降であれば同じです．違っていたのは7.3以前の話ですね． http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c782 Sat, 18 Feb 2006 01:17:59 +0000 komura [訪問者] c780@http://blog.ohgaki.net/ 遅くなってしまいましたが、pg_set_client_encoding( 'SJIS' ) を実行してから同様の事を検証してみました。<br /> <br /> 結果としては、<br /> <br /> SET client_encoding TO 'SJIS'; <br /> <br /> を実行してから SQL を実行したのと同様の結果になりました(0x9527 が SJIS の文字として見なされ、SQL インジェクション可能)。<br /> <br /> PHP 5.1.2 と PostgreSQL 8.1.3 で確認しました。<br /> <br /> あと、ご指摘通り、pg_prepare() と pg_execute() によるプリペアードクエリでは問題ありませんでした(文字コードが SJIS の場合でも SQL インジェクションを起こせない)。<br /> <br /> PHP 側でこれらの関数が導入されたのは PHP 5.1.0 以降のようですので、それより前のバージョンでは文字コードに SJIS を使用しないようにするしかないように思います。
結果としては、

SET client_encoding TO 'SJIS';

を実行してから SQL を実行したのと同様の結果になりました(0x9527 が SJIS の文字として見なされ、SQL インジェクション可能)。

PHP 5.1.2 と PostgreSQL 8.1.3 で確認しました。

あと、ご指摘通り、pg_prepare() と pg_execute() によるプリペアードクエリでは問題ありませんでした(文字コードが SJIS の場合でも SQL インジェクションを起こせない)。

PHP 側でこれらの関数が導入されたのは PHP 5.1.0 以降のようですので、それより前のバージョンでは文字コードに SJIS を使用しないようにするしかないように思います。]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c780 Tue, 14 Feb 2006 21:29:03 +0000 Yasuo Ohgaki [メンバー] c775@http://blog.ohgaki.net/ http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html<br /> <br /> Iliaさんも同じ事を書いているのですね。と思ったら、リンク先のブログにもリンクあるし。よく読まないといかんですね。
Iliaさんも同じ事を書いているのですね。と思ったら、リンク先のブログにもリンクあるし。よく読まないといかんですね。]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c775 Tue, 14 Feb 2006 21:18:15 +0000 Yasuo Ohgaki [メンバー] c774@http://blog.ohgaki.net/ もう一つ対処方法を。<br /> <br /> プリペアードクエリを使用すればエンコーディングが違っていても（本来これ自体問題なのですが）SQLインジェクションは出来ないはずですね。<br /> <br /> エスケープ処理のミスのみでなく、エンコーディング設定のミスを防ぐためにもプリペアードクエリを使用した方が良いですね。<br />
プリペアードクエリを使用すればエンコーディングが違っていても（本来これ自体問題なのですが）SQLインジェクションは出来ないはずですね。

エスケープ処理のミスのみでなく、エンコーディング設定のミスを防ぐためにもプリペアードクエリを使用した方が良いですね。
]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c774 Tue, 14 Feb 2006 21:03:08 +0000 Yasuo Ohgaki [メンバー] c773@http://blog.ohgaki.net/ 今日のところはちょっと時間不足なので、最後にkomuraさんコメントありがとうございます。<br /> <br /> pg_set_client_encoding関数以外でエンコーディングを変えると問題になる事は知っていましたが（自分が実装した関数なので当たり前ですが）SETで変えるのと同じ、と思われている方もいるはずですね。非常に参考になりました。<br /> <br /> 時間が出来たらもう少し調べて確認してみたいと思います。<br />
pg_set_client_encoding関数以外でエンコーディングを変えると問題になる事は知っていましたが（自分が実装した関数なので当たり前ですが）SETで変えるのと同じ、と思われている方もいるはずですね。非常に参考になりました。

時間が出来たらもう少し調べて確認してみたいと思います。
]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c773 Tue, 14 Feb 2006 20:53:21 +0000 Yasuo Ohgaki [メンバー] c772@http://blog.ohgaki.net/ mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.<br /> <br /> とあるので、MySQLもmysql_real_escape_stringを使っていればどんな文字列で大丈夫なように作ってあると思います。仕様通りのエンコーディング指定をしていてもダメならMySQLのセキュリティホールという事に。
とあるので、MySQLもmysql_real_escape_stringを使っていればどんな文字列で大丈夫なように作ってあると思います。仕様通りのエンコーディング指定をしていてもダメならMySQLのセキュリティホールという事に。]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c772 Tue, 14 Feb 2006 20:46:09 +0000 Yasuo Ohgaki [メンバー] c771@http://blog.ohgaki.net/ 正しい設定方法を書いていなかったですね。<br /> <br /> pg_set_client_encoding関数を使ってクライアントエンコーディングを設定すれば問題なく処理されるはずです。これが正しく処理されていないならPostgreSQLのセキュリティホール :)<br /> <br /> 専用の関数は単純なラッパーの場合もありますが、意味があって専用関数になっている場合もあります。内部仕様を完全に把握していない場合は専用関数を使うべきと思います。<br />
pg_set_client_encoding関数を使ってクライアントエンコーディングを設定すれば問題なく処理されるはずです。これが正しく処理されていないならPostgreSQLのセキュリティホール :)

専用の関数は単純なラッパーの場合もありますが、意味があって専用関数になっている場合もあります。内部仕様を完全に把握していない場合は専用関数を使うべきと思います。
]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c771 Tue, 14 Feb 2006 20:43:17 +0000 Yasuo Ohgaki [メンバー] c770@http://blog.ohgaki.net/ なるほど。文字エンコーディングの違い問題が発生する典型的な例ですね。<br /> <br /> 時間が無くて試していませんが、<br /> <br /> SET client_encoding TO 'SJIS'; <br /> <br /> 接続先のDBサーバにこのSQLを送信すると、クライアントのエンコーディングとサーバのエンコーディングが別のエンコーディングになるので基本的に間違っています。<br /> <br /> 要するにこうするとクライアントライブラリ（libpq）はサーバ側がSJISを使っている、ということを知らずに処理する事になります。<br /> <br /> PostgreSQLサーバはSJISエンコーディングをサポートしていないのでクライアント側でクライアントエンコーディング->サーバエンコーディングに変換していた、と思います。（ここの記憶が怪しいですが、SETでインジェクションが可能になるならこうなっているはず。libpqの接続構造体がエンコーディングを保持していた記憶は確かなはず）<br /> <br /> 文字エンコーディングの違いでXSSが発生するのと同じで、SQLインジェクションできるようになるのは普通(?)の事だと思います。<br /> # もしかして普通はそう考えない?<br /> <br />
時間が無くて試していませんが、

SET client_encoding TO 'SJIS';

接続先のDBサーバにこのSQLを送信すると、クライアントのエンコーディングとサーバのエンコーディングが別のエンコーディングになるので基本的に間違っています。

要するにこうするとクライアントライブラリ（libpq）はサーバ側がSJISを使っている、ということを知らずに処理する事になります。

PostgreSQLサーバはSJISエンコーディングをサポートしていないのでクライアント側でクライアントエンコーディング->サーバエンコーディングに変換していた、と思います。（ここの記憶が怪しいですが、SETでインジェクションが可能になるならこうなっているはず。libpqの接続構造体がエンコーディングを保持していた記憶は確かなはず）

文字エンコーディングの違いでXSSが発生するのと同じで、SQLインジェクションできるようになるのは普通(?)の事だと思います。
# もしかして普通はそう考えない?

]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c770 Tue, 14 Feb 2006 16:58:05 +0000 komura [訪問者] c769@http://blog.ohgaki.net/ リンク先ではデータベース側で文字列を SJIS として処理している場合は、mysql_real_escape_string() や pg_escape_string() 等のデータベース専用のエスケープ関数を使用してもエスケープ処理が回避されてしまうことが書かれています。<br /> PostgreSQL でも、SET client_encoding TO 'SJIS'; を実行した後、"\x95' OR a = a; --" のような文字列を渡して、pg_escape_string() でエスケープすると、SQL インジェクションを引き起こすことが可能であることを確認しました(PostgreSQL 8.0.6/8.1.3)。<br /> 0x9527 という文字は本来は SJIS としては認められないはずですが、PostgreSQL では SJIS のマルチバイト文字として処理されるようです。 PostgreSQL でも、SET client_encoding TO 'SJIS'; を実行した後、"\x95' OR a = a; --" のような文字列を渡して、pg_escape_string() でエスケープすると、SQL インジェクションを引き起こすことが可能であることを確認しました(PostgreSQL 8.0.6/8.1.3)。
0x9527 という文字は本来は SJIS としては認められないはずですが、PostgreSQL では SJIS のマルチバイト文字として処理されるようです。]]> http://blog.ohgaki.net/addslashesa_la_a_a_ua_sa_pa_fa_a_bc_a_ma#c769