なぜPHPアプリにセキュリティホールが多いのか? 「第42回 PostgreSQL 9.0に見るSQLインジェクション対策」のまとめ
-
- いいね！9
Yasuo Ohgaki (大垣靖男)
@yohgaki
ツイッターで説明するような事ではないから、どこかで解説するほうが良いのかな。そのうち何処かで解説することにします RT @ockeghem: いえ、分かりません
2011-05-20 12:04:48
Moriyoshi Koizumi
@moriyoshit
まずどんなことがあっても「プリペアードステートメントでは不十分だ」って言説にしちゃまずいと思うんですよね。
2011-05-20 12:06:18
Yasuo Ohgaki (大垣靖男)
@yohgaki
@ockeghem テーブルを分割するのは良くある話ですね。入力でバリデーションするのはもちろんですが、入力のセキュリティと出力のセキュリティは別個の物として対策するは多重防御の基本です。管理ツールとかは識別子がパラメータになるケースは普通ですね。
2011-05-20 12:09:28
Yasuo Ohgaki (大垣靖男)
@yohgaki
@ockeghem プリペアードクエリは不完全なのだからエスケープをしっかりしろ、と言うことは必要ですね。プリペアードクエリのパフォーマンスチューニングにパラメータを埋め込むのも結構一般的かな。
2011-05-20 12:12:11
Yasuo Ohgaki (大垣靖男)
@yohgaki
同意するしないの問題ではなく、そうなってますから RT @ockeghem: @yohgaki 同意できません
2011-05-20 12:23:57
徳丸 浩
@ockeghem
@yohgaki テーブル分割と識別子のエスケープは関係ないと思います。識別子を外部に持ち出す必要がないし、やるとしたら識別子の一覧（ホワイトリスト）でのチェックでしょう。
2011-05-20 12:24:43
徳丸 浩
@ockeghem
そうなっているのは大垣ワールドの中だけでは? RT @yohgaki: 同意するしないの問題ではなく、そうなってますから RT @ockeghem: @yohgaki 同意できません
2011-05-20 12:25:26
徳丸 浩
@ockeghem
パフォーマンスチューニングのパラメータを外部から操作できたら脆弱性ではないですか? RT @yohgaki: @ockeghem …プリペアードクエリは不完全なのだからエスケープをしっかりしろ…プリペアードクエリのパフォーマンスチューニングにパラメータを埋め込むのも結構一般的かな
2011-05-20 12:28:15
徳丸 浩
@ockeghem
プリペアードクエリだけでは対処できない場合があるのは確かですが、「原則としてプリペアードクエリを用い、それが適用できない箇所についてはバリデーションなどで対処する」といえば良いだけです @yohgaki: @ockeghem プリペアードクエリは不完全なのだからエスケープを
2011-05-20 12:34:11
Yasuo Ohgaki (大垣靖男)
@yohgaki
構文解析時にパラメータが分からないとクエリプランナがトンでもなプランを作る場合もあって、埋め込むと劇的に高速化することも RT @ockeghem パフォーマンスチューニングのパラメータを外部から操作できたら脆弱性ではないですか?
2011-05-20 12:39:29
Yasuo Ohgaki (大垣靖男)
@yohgaki
入力と出力のセキュリティ対策は独立してるべきなので、出力時にエスケープでOKならそれで良いかと RT @ockeghem プリペアードクエリだけでは対処できない場合があるのは確かですが、「原則としてプリペアードクエリを用い、それが適用できない箇所についてはバリデーションなどで対処
2011-05-20 12:40:59
Yasuo Ohgaki (大垣靖男)
@yohgaki
入力時にホワイトリストでチェックに異論はありません。やるべきです RT @ockeghem: @yohgaki テーブル分割と識別子のエスケープは関係ないと思います。識別子を外部に持ち出す必要がないし、やるとしたら識別子の一覧（ホワイトリスト）でのチェックでしょう。
2011-05-20 12:43:24
Yasuo Ohgaki (大垣靖男)
@yohgaki
世の中には分散DB、パーテションしたDBは沢山ありますよ RT @ockeghem: そうなっているのは大垣ワールドの中だけでは? RT @yohgaki: 同意するしないの問題ではなく、そうなってますから RT @ockeghem: @yohgaki 同意できません
2011-05-20 12:44:20
徳丸 浩
@ockeghem
そこは同意です。でも、テーブル名などをエスケープする必要はないということです RT @yohgaki: 世の中には分散DB、パーテションしたDBは沢山ありますよ
2011-05-20 12:46:39
Ikeda Masakazu
@ikepyon
@yohgaki 分散DB、パーティションしたDBがあったとしても、その識別子は有限個に特定することが出来ると思います。それであれば、ホワイトリストのチェックなりで十分。エスケープが必要なのはその対象（ここでは識別子）が任意（何でもいい）場合ではないですか？
2011-05-20 12:48:18
Yasuo Ohgaki (大垣靖男)
@yohgaki
論外な例だけど、無意味に顧客別のテーブルを作ってたアプリケーションも見たことも、何故かフィールドが追加されていくアプリとかも。これらはDBの設計ミスのケース。
2011-05-20 12:48:19
Ikeda Masakazu
@ikepyon
検索エンジンの検索文字列なんかは何が入るかわからない（任意の値）からエスケープが必要だけど、AかBかのどちらかであれば、AかBであることを確認するだけでOK
2011-05-20 12:49:25
Yasuo Ohgaki (大垣靖男)
@yohgaki
@ikepyon ホワイトリストのバリデーションは入力時。エスケープは出力時の対策として独立して行いましょう、と言う話です。多重防御の考え方です。
2011-05-20 12:50:02
Ikeda Masakazu
@ikepyon
@yohgaki その有効性がわかりません。テーブル名などはホワイトリストのチェックで安全（＝既にエスケープされているもので確認すればOK）とわかっているのに、必要のないエスケープ処理が何故必要なんでしょう？
2011-05-20 12:54:14