ikepyonのだめ人間日記

セキュリティに関することを書いていく予定。

数に型のない言語におけるSQLインジェクション対策に対する考察(3)(from id:ripjyrさんとこ)

http://d.hatena.ne.jp/ockeghem/20070503
結構思っていることと同じだったりして。

入力データの妥当性検証というのは、セキュリティ対策という要請からではなく、適切なデータをアプリケーションが常に正しく処理する必要があるので、必要だと思う。なぜなら、データの内容によって、意図しないデータの書き込みや、変な状態での異常終了とかが起こってほしくないというわけで(これ自体、セキュリティインシデントの1つなんだけどね)。
これを防ぐには、入力データが正しいかどうか(数値項目に数値だけが含まれているかとか、選択肢の中のデータだけかとか)を確認するのが最も確実で、簡単な方法だと思う。

でも、あくまで、入力データの妥当性検証でできるのは、型チェックだとか構成データのフォーマットチェックだとかそういった形式的な確認であり、意味的な確認(SQL文としてつかったとき、どうなるか?とか、XSSが発生しないか?)にはこの段階では、どの様な場面で使われるか判断つかない(最初の段階で、仮に分かったとしても、今後の拡張でどういう使われ方をするか分からない)から実装すべきではないと思う。意味的な確認、対策を入力データの妥当性検証でやってしまうと1つのデータを複数のアプリケーションへの出力として利用している場合(可能性も含む)があると、非常に複雑になり、プログラムが汚くなる。
実際に意味的な対策(SQLインジェクションが起こらないかとか)は入力データを使う直前になって、初めて可能となるのだと思うのですよ。それまでは、どういったことに入力データが使われるか分からないので、下手にデータの内容を変更しない方がいいのは当たり前(変な変換を最初にしてしまって、別のところで問題が出るのは良くあることだし)でしょ?

なので、そのデータが、数値か文字か、変数に型のある言語かどうかに関らず、入力データのフォーマット等の妥当性検証は必ず行うことがプログラムとして自然だし、出力時に意味的な対策(エスケープ処理)を行うこともプログラムとして自然だと思うのですよ。

ホスト系の開発では、結構こういったことが経験上普通の気がするのだけど、どうなんでしょ?
http://d.hatena.ne.jp/ikepyon/20061201#p2