例えば、バインドメカニズムがまだ広まっていなかった頃、数値型の SQLインジェクションを防ぐためには、入力値検証を行うのが一般的(*1)でしたから、“セキュリティの要請”として入力値検証が重要な面もあったかも知れませんね〜。

*1) 型変換も一般的でしたけどｗ

s/上手/上図/ ですね :-)

私も基本はエスケープという考え方を広めていきたいと思っています。ただし、少し複雑なアプリケーションを作ろうとすると、「例外」という問題が発生する可能性が非常に高いのでは？と感じることが多くなってきました。最も単純と思われるSQLInjectionの対策にしても、バインドメカニズムが使用出来ないケースは存在します。
エスケープだけでは防げないセキュリティの問題は存在していて、それらは入力値検証によって対策しなければならないという現実もあります。その部分のフォローが必要かなと感じる今日この頃です。

また、セキュリティの要請ではなく業務要件という考え方は、いまいち理解出来ません。例えば、パラメータの改ざんにより本来アクセス出来てはならないデータにアクセス出来てしまう問題があったとしたら、それは一般的なセキュリティの問題ではないということでしょうか？

＞エスケープだけでは防げないセキュリティの問題は存在していて、
＞それらは入力値検証によって対策しなければならない

そんなケースはないと思いますよ。

＞パラメータの改ざんにより本来アクセス出来てはならないデータにアクセス出来てしまう問題

業務要件としてのセキュリティ要件であって、セキュアコーディングの話ではないですね。

突っ込みありがとうございます>みなさま
ミドルウェアとアプリケーションの役割は、すぱっと分かれるわけでもないので、ここで書いた話が絶対不変の真理などというつもりはありません。こう考えたら、おおむねうまく整理できるのではないかという提案です。
あと、入力値検証というのはあくまで入力値を受け取った時点での検証であって、その値を使う時にチェックしなければならないケースはあり得ると思います。例えば、リダイレクタに指定するURLに改行が入っていないかとかです。しかしこれとて、リダイレクタのAPI側で本来チェックすべきものだと思います。

>そんなケースはない・・・
お、そうなんですか。私が知らない間に、言語は進化しているようですね。
>業務要件としてのセキュリティ要件・・・
なるほど、セキュリティ要件を書く人は大変ですね。

masaさん
意見を述べるなら根拠を出して表明するようにしませんか。
「俺は知ってるけどお前ら知らないから言えるんじゃ」
と言われているようにしか聞こえません。
masaさんの方が間違っているかもしれないのに、
手の内を明かさないのでは誰も否定できません。

続けて。
masaさん曰く
「パラメータの改ざんにより本来アクセス出来てはならないデータにアクセス出来てしまう問題があったとしたら、それは一般的なセキュリティの問題ではないということでしょうか？」
意味がわからないです。「パラメータの改ざん」と言ったらなんでもそれに該当しますし、「本来アクセスできてはならないデータにアクセスできてしまう」と言ったら、セキュリティ上の脅威のCIAのCの全部がそれなのですから、何のことを指しておっしゃているのか特定できません。
そんな質問をしておきながら、「それは一般的なセキュリティの問題ではないということでしょうか？」なんて「そんなわけねーだろ」と言わんばかりの質問を投げかけるのは失礼です。

> 別の通りすがりさん
すいません、例をあげます。
SQLInjectionでしたら、
"select * from usertable order by " + columName + asc_or_desc;
といったコードでSQLInjectionの問題が発生した場合です。クォートされない個所への文字列挿入全般の問題なので、他にも例はたくさんあるかと思います。
このような問題にエスケープで対策出来ますか？分岐ロジックを書いていますか？実際は、入力値検証で対応するのではないですか？
と、いうことです。

パラメータの改ざん・・・のくだりは、アクセス認可と置き換えればよいでしょうか。
http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/102.html
ここの図5の三段階目の入力値検証をイメージしています。

カラム名なら「"」で括るのが正しいですよ。
カラム名に予約語があったら困るので当然そういう文法が言語に用意されているわけです。http://www.postgresql.jp/document/pg653doc/j/user/syntax.htm

「asc_or_desc」のところは、そういうSQL文の作り方をしちゃいけないってだけです。入力のところでvalidationしなければならないってものではありません。

図5のものは、今ここで言われている validation のことではありませんね。脆弱性対策というより元々仕様で要求されているセキュリティ機能の一つでしょう。それが見えてはいけないことが仕様で定義されていなければこれが欠陥なのかどうか機械的判別はできないわけで、検査者の視点で言えば、検査者はそのとき「見えてはいけないもの」だということを常識で判断するのでしょう。それは仕様に欠陥があるという話で、ここで言われている脆弱性対策としての validation とは関係がないでしょう。

別の通りすがりさん
> カラム名なら「"」で括るのが正しいですよ。
恥ずかしながら知りませんでした、ありがとうございます。この指定については少し調査してみます。
asc_or_descの問題は「そういうSQL文の作り方をしちゃいけない」と言われると、「検証済ならよいのでは？」と思ってしまいます。ただ、入力値検証で対応しなければならない訳ではないですね。すいません。

>・・・それは仕様に欠陥があるという話で、・・・
常識で判断出来ることを仕様に書かなければならないとしたら、「セキュリティ要件を書く人は大変ですね。」という感想に変わりはありません。
私は、hidden値やselectboxで選択された値など、ユーザに悪意がない限り通常は改ざんされることがないデータが改ざんされ、その結果システムに悪影響が及ぶならば、業務要件がどうであれセキュリティの欠陥だと考えていますので。

フレームを発生させてしまい申し訳ありません。
カラム名のクォートについて調査した結果だけ報告して最後とさせて頂きます。
PostgreSQL8.2.4で検証したところ、「"」によって「"」がエスケープされますので、SQLInjection対策として有効であることが確認できました。テーブル名やカラム名に含まれる特殊文字のエスケープに(データベース名にも)適用が可能な、エスケープ関数が用意されている言語も多いようです。
http://www.go-pear.org/manual/ja/package.database.mdb2.intro-quote.php
http://msdn2.microsoft.com/ja-jp/library/system.data.common.dbcommandbuilder.quoteidentifier(VS.80).aspx
asc_or_descの部分は、「動的な入力値をそのまま使用して構文を組み立ててはいけない」と、理解することが出来ました。
不快な思いをさせてしまった方には深くお詫び致します。