「MySQL、ブラインド SQL インジェクションにより情報漏洩が発生」記事へのコメント

っていうか、これ

[gonta (11642)]

「ブラインド」SQLインジェクションって、区別するものなのかな？SQLインジェクションそのものだと思うんだけど。SQLインジェクションの種類わけならそれでもいいと思うんだが、何か別物のように聞こえてしまって/扱っているようで、違和感感じました。

PHPのソーシャルアプリを使っている人間に聞いたら、PDOでPlaceFolderを使ったクエリ作成（prepare使うやつ）は、使わないんだとか。PDOって処理速度が重いので、PV稼がなくてはいけないソーシャルアプリには不適切なんだとか。教科書どおりなら、SQLインジェクション防ぐのはprepare()が有効だと思うんだが・・・

--
-- gonta --
"May Macintosh be with you"

Re:

[Anonymous Coward]

さすがPHPer、期待に違わぬ残念さ。
Javaで速度を稼ぐためにPreparedStatementをやめたなんて話は聞いたことがないなあ(検索条件が動的に変化するので使えなかったということはあるけど)。むしろかえってparseが必要な分遅くなるとしか思えないんだけど。
実はDBMSがなんちゃってPreparedStatementしか用意されていないMySQLだったなんてオチはないよね。

Re:っていうか、これ

[ootori (41812)]

詳細聞かずに、PHPerだと無条件でたたくのはやめたほうが良いと思いますよ。

たとえばJAVA屋さんだとDBコネクションをプーリングするのが常識みたいになってますけど、
ソーシャルアプリ業界ではプーリングするのは逆にご法度みたいな部分があったり
ジャンルによってノウハウって違いますからね。

DBあんまり詳しくないんでまちがってたらすいませんけど、毎回DB接続をオープン、クローズしてたらprepared statementでのSQL解析をするぶん速度は落ちるのではないでしょうか？
そういう意味ではPrepare statementやめて生SQL生成してそれ投げるというのはわかる気はしますね。

月間一億PV程度のしょぼいサイト(秒間最大200PVくらい)までしか扱ったことない私はprepare statement使っても問題ないとは思いますが、ソーシャルアプリとか秒間数千から数万のクエリさばく世界ですからね。
中途半端な知識の人間が根拠なしにPreparedStatementをやめたなんていってるとはおもえないんですけど･･･

Re:っていうか、これ

[kou1slash (5979)]

prepared statement ってクエリキャッシュに載せるために使うものでコネクションプーリングとはあまり関係ないと思ってたんですがあってますかね？
「毎回DB接続をオープン、クローズした時のSQL解析」を高速化するためのの物という把握でした。

DBは幾らか分かるんですが、アプリは素人なんで変なコト言ってるかもしれませんけど…。

Re:っていうか、これ

[ootori (41812)]

このあたりの質問が私の言いたかったことに近いですね。

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=5374&forum=12 [atmarkit.co.jp]
> PreparedStatementによりプリコンパイルされたSQLは
> コネクションをクローズした後もキャッシュされているのでしょうか？

コネクションクローズしたあともプリコンパイルされたSQLが保持されているということであれば納得です！
違うなら生SQLの方がはやいですよね？？

Re:

[Anonymous Coward]

> 違うなら生SQLの方がはやいですよね？？
なんで?

Re:っていうか、これ

[ootori (41812)]

プリコンパイルしたSQLのキャッシュがない前提でのはなしですが
【プリコンパイルあり】
prepared,execute(プリコンパイルされたSQL) 2回通信または2回実行
【プリコンパイルなし】
execute(生SQL) 1回通信または1回実行
だとおもうんですが？ちがいますか？

Re:

[Anonymous Coward]

そもそもどうしてstatementがキャッシュされることがないなんて非現実的な仮定にこだわるんですか? 性能が重要なサーバじゃなかったの?

Re:っていうか、これ

[ootori (41812)]

> そもそもどうしてstatementがキャッシュされることがないなんて非現実的な仮定にこだわるんですか? 性能が重要なサーバじゃなかったの?

ぼくが書いた内容をちゃんと読んでますか？
こだわるってるんじゃなくてわからなくてずっと質問してるんですが･･･
質問してる人間に質問で返すなと･･･

PDOでコネクションクローズしたあとでもstatementがキャッシュにのっているのであればおっしゃるとおりだと思います。
ただ、コネクションクローズしたあとでもstatementのキャッシュがつかえるのかどうかそこがわからんのです。
そしてその部分はだれも教えてくれない･･･

Re:

[Anonymous Coward]

毎回コネクションクローズしてたらそのコストがでか過ぎて、
preparedだろうとそうでなかろうと大した差がない。

そもそもプーリングがご法度って本当なの？
ソース出してくれませんかね？

Re:っていうか、これ

[ootori (41812)]

> ソース出してくれませんかね？

もう他の人がだしてるよ・・・

Re:

[Anonymous Coward]

PHPでコネクションプーリングするとき、普通はpg_pconnectを使う。これを使うとプロセスが終了するまでコネクションを開きっぱなしにする。Apacheでmod_phpを使うと1つのプロセスは同時に1つのPHPスクリプトしか実行できないから、pg_closeしてもそのコネクションを再利用できるのは同時実行されている他のプロセスのスクリプトではなく、同じプロセスが実行する次のスクリプトになってしまう。これによって接続しているだけでメモリを占有するのに何もしないコネクションが大量発生し、性能が劣化する。元々MySQLはコネクションの作成がとても速いから、こんな不完全なプーリングを使うよりは、そのつどpg_connectして使い終わったらすぐpg_closeした方がメモリ要求が少なくなってトータルでは効率的。

Re:っていうか、これ

[ootori (41812)]

ですよね･･･
ソーシャルアプリ界隈って言ったのが癪に障ったのかえらく叩かれてしまいました。

ソーシャルアプリに限らずPHPの高負荷サイトでpconnect使わないのは比較的常識の部類だと思ってたんですけどね（グッドノウハウなのかバッドノウハウなのかはさておいてね）。

それにしても「使う技術によってノウハウは違うよ」って言っただけのつもりだったのに何でこんなに叩かれたんだか･･･

Re:

[Anonymous Coward]

なら最初からPHP+MySQLの話と書けばいいのに。
それに叩かれてるのはpconnectじゃなくてprepared statementの話だよね。
prepared statementでなく、生文字列を組み立てて速度を稼ぐのは明らかにバッドノウハウ。
他のツリーにもあるけど、PDOとMySQLの実装がバカなのが原因。

Re:

[Anonymous Coward]

考える余地もないと思いますが、説明の仕方に問題があるからでしょう。

Re:っていうか、これ

[b-wind (13096)]

＞PHPの高負荷サイトでpconnect使わないのは比較的常識の部類
それは比較的常識に考えていいけど、まぁバッドノウハウの類だな。

pconnect 自体が単なる永続的接続で、にコネクションプールと呼べる物じゃ無いって事を忘れてるよ。

Re:

[Anonymous Coward]

そういう当てこすりをしたいなら、技術論の場には出てこないほうがいいんじゃないかな。
多くは技術的に正しいか正しくないかを論議しようとしてるよね。

#1926755 の論点を洗うと、
1. コネクションプーリングはソーシャルアプリ界隈ではご法度
2. Prepared Statementを使うとSQLのパースは遅いのではないか
の二点になると思うけど、これでいい？

1に関して繋がっているのは #1926785 #1926836 #1927085 で叩きになってるようには見えないけどどうかな。
#1926793 の「本当にこれ合ってるの？」に対して反論が出てきてないのが気になる。
#1927085 の通りだとするとMySQL特有で、PHP+Pos

Re:っていうか、これ

[ootori (41812)]

これベースに話してるんだと思ってたんですが･･･
http://srad.jp/security/comments.pl?sid=527293&cid=1926729 [srad.jp]

で、私の意見は「使う技術によってノウハウは違うよね？」「詳細聞かずに残念いっちゃだめだよ」の２点ですよ？

他の発言に関しては質問してる内容を質問でかえされたから私はこう思ってるんだけど違うのかな?って考えをいっただけで議論するつもりはないですよ･･･
そんな議論ができるほど立派なエンジニアではないですから･･･

> 叩きが入っているようには見えないんだがどう？
その後馬鹿馬鹿言われてたので、たたかれたと表現しましたけどね･･･馬鹿とかいわれなければたたかれたとは言いませんよ。それとも馬鹿と相手に対して言い放つのは議論であって叩いてないということでしょうか？

Re:っていうか、これ

[bero (5057)]

逆。prepared statementを使うとクエリキャッキュがきかない
http://dev.mysql.com/doc/refman/5.1/ja/query-cache-how.html [mysql.com]

Re:っていうか、これ

[quabbin (17251)]

http://dev.mysql.com/doc/refman/5.1-olh/ja/query-cache.html [mysql.com]

注意
MySQL 5.1.17 以降、項4.5.5.1. 「クエリキャッシュの動作」に説明されている条件の下で、クエリーキャッシュは準備済みステートメントに使用されます。5.1.17 より前では、クエリーキャッシュは準備済みステートメントに使用されません。

Re:っていうか、これ

[quabbin (17251)]

読んでみたら、もう少しバージョンによる制限がきつかったようで。
http://dev.mysql.com/doc/refman/5.1-olh/ja/query-cache-operation.html [mysql.com]

MySQL 5.1.21 より前では、PREPARE および EXECUTE で実行された準備済みステートメントの場合、? パラメータマーカーを含んでいるものはキャッシュされません。

とあるので、5.1.21以降であれば普通に使えるように読めますが、いかがでしょう？

# しかし、キャッシュが使用されない場合の注意書きが多いですね…

Re:

[Anonymous Coward]

そういうPHPの不具合を回避するためのバッドノウハウだったはずのものがいつの間にか「普遍の真理」になってしまうのは勘弁してもらいたいですね。

Re:っていうか、これ

[shuichi (572)]

色々コメントついてるけど論点がずれてない？
別にprepared statement が重要な訳じゃないと思うけど。
要はエスケープ処理を確実にする為なんだからプレースフォルダを解決する関数ひとつ作ればいいだけじゃん。
1っ箇所だけならまず間違えないし、prepared statement 使ってる人なら簡単な説明で理解してくれるはずだし。

Re:

[Anonymous Coward]

ソーシャルアプリ業界ではプーリングするのは逆にご法度

これってどんな理由でご法度にしているのでしょう。
効率性の問題ではないように思えるのですが。

Re:

[Anonymous Coward]

自己レス。
元ネタはきっとこの辺ですね。
Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～ [slideshare.net]。
DB接続への待ち行列を少なくすることが重要な負荷対策であると。

接続だけして作業してないコネクションがDBの負荷に影響を与えるのだろうかと。
メモリ増やしてDB側の接続上限を上げればよいだけに見えますが、少し実験してみないと分からないところで。

Re:

[Anonymous Coward]

RDMS の機能の半分を占める (!) コネクション認証/識別を使用してない、ってことと等価ですからねえ。

計測してみたよ

[Anonymous Coward]

論より証拠で、JavaでPreparedStatementを使う場合と、そうでない場合を比較してみました。
単純なSELECT文で、以下の条件で10000回ループさせました。

1. PreparedStatementをループの外で生成して使い回し
2. 1回ごとにPreparedStatementを生成
3. 1回ごとにSQLを生成して、executeQueryで生のSQLを実行

1.が速いのは当然として、2と3のどちらが速いかが問題だと思いますが、結果としては平均で、
1. 403ms
2. 7124ms
3. 7523ms

となりました。つまり、PreparedStatementを使わない理由はないということです。
Java+Oracleでのテストなので、PHP+MySQLがヘボイ実装という可能性はありますが:P

Re:計測してみたよ

[ninestars (5792)]

比較するならば Java+MySQL で同じテストをしてみましょう。

Re:

[Anonymous Coward]

自分PHPerで同じように測ったら、１が速いのは当然として、２より3のほうが速いです。７１００と７５００のような微小な差ではなくもっと大きい。
さらに、PHP(ウェブ)の場合リクエストごとに接続するのがスタンダードだから、毎回Prepare作成しないといけない。
一度Prepareしたものを同スクリプト内で再利用する機会はほとんどない。

ローカルアプリのように起動したら終了するまで接続を維持するようなものならいいですけど、ウェブのようなものには向いてないような気もする。
ただの勉強不足ですけど。

Re:計測してみたよ

[quabbin (17251)]

DBMSの物とバージョン、使ったライブラリを明示するべきかと

Re:計測してみたよ

[taka2 (14791)]

ちょっと気になったので、PHP上でDBおよび接続手段を変えて測ってみました。
FreeBSD 7.2-RELEASE/amd64上で、PHP 5.3.6、MySQL 5.1.33、PostgreSQL 8.4.6 を使ってます。

integer な主キーに対するSELECTを1万回実行した時の、1回あたりの処理時間(マイクロ秒)
(接続は、単なるDBへの接続と切断を1万回実行)

                prepare    生SQL
        接続 1回だけ 毎回   生成
MySQL
mysql    161                 44
mysqli   180    48    134    48
PDO      151    47     51    50
MDB2     921   609    996   124
PostgreSQL
pg      8260   122    245   159
PDO     7861    91    366   407
MDB2   13045   535   1210   406

PostgreSQL はprepareしておいた方が速いですが、MySQL は毎回生SQL文を生成してもほとんど同じ。
MySQL PDO だけは、毎回prepareしても似たような数値なので、内部で自前でSQL文を組み立ててるんだと思います。
まあ、エスケープ処理のアルゴリズムさえ間違えてなければ、その方が速いし悪いことじゃないとは思いますが…釈然としない…

あと、こうしてみると PostgreSQLは接続にかかる時間が桁違いですね。
これだと、Webアプリケーションでコネクションプーリングしたくなるのも納得です。

あくまで私の知識の範囲内ですが……

[Anonymous Coward]

この一連のコメントに対する確認なのでここにぶらさげます

プリペアードクエリ：クライアント側で利用選択する機能。
　実行計画を事前に作成し、実際にいれる値だけを変えて連続実行
　→ どちらかというと実行計画の使いまわしより
　　 プレースホルダによる自動エスケープの恩恵が大きい。

ステートメントキャッシュ：サーバ側自動機能。
　プリペアードクエリの実行計画をキャッシュ。
　→ あまり意味がないとのことでサーバ側で無効にされている

クエリキャッシュ：サーバ側自動機能。意外とパフォーマンスに影響
　問い合わせで同じデータを返すものをキャッシュ。
　→ パラメータ付きのプリペアード