技術日記
多重のセキュリティとか出力時のバリデーションとかEdit

なぜPHPアプリにセキュリティホールが多いのか?:第44回 セキュリティ対策が確実に実施されない2つの理由|gihyo.jp … 技術評論社

gihyo.jp セキュリティ対策が確実に実施されない2つの理由

はてなブックマーク - 第44回 セキュリティ対策が確実に実施されない2つの理由|gihyo.jp … 技術評論社

なんではてブでこんなに叩かれているんだ? Rails関連はよう知らんけど、それ以外の内容で特に叩かれるようなことは書いてないと思うんだけど?

「多重のセキュリティ対策」って言葉に引っかかっている人がいるみたいだけど、単に「既にチェック済み,これは数値だからエスケープ処理は不要,などとの誤った判断からエスケープ処理を行っていないコード」みたいな事例に対して、入力値でバリデーションしたから出力値はエスケープしなくていいとか考えるなって言っているだけでしょ。

で、上記みたいな誤った判断をする人がその理由として、「だってDRYって言うし、いったんこの入力値に対してはチェックコードを書いたから、出力時の処理は書かなくていいよね」とか言いかねないから、「セキュリティ対策とコーディングのベストプラクティスは相反する」と言ってるんじゃないの? 結局ここで言うベストプラクティスってのは「重複処理を排除した効率よいコード記述」のことみたいだし。「それを重複と考えるのはおかしい」とか言っても、それを重複と考えるような馬鹿を前提とした文章だって読み取れるじゃん。

あと出力時のバリデーションに関しては、「1と2の対策が不可能な場合は出力時にバリデーション処理を行う」と書いてあるとおり、どうしてもエスケープなどを使った安全な出力ロジックが使えない場合は、しょうがないから出力に関してもバリデーションしようね、という話になっていて、別に推奨しているわけじゃないし、実際特殊な環境向けの出力ではあり得る話だと思うんだけど。

それにしても「セキュリティ対策」って言葉は曖昧で良くないな。

  1. 普通に動作させるために必要な設計と実装(そして、それができなかった際に発生するバグ)。
  2. 情報漏洩や情報破壊を引き起こしうるバグに対する注意。
  3. 積極的なセキュリティアタックに対しての対抗策。
それらが全部なんとなく「セキュリティ対策」でくくられてしまうけど、全部混ぜて議論すると焦点がぼやけてぐだぐだになる。どこまでわかっている(問題にしている)人に対して、何を伝えたいのかがそれぞれ違ってくる。

Published At2011-12-01 13:08Updated At2011-12-01 13:08