分類の複雑さ
上の文章を書いて、思ったのだけど、下手に攻撃手法が細分化されてるから混乱しやすい?
脆弱性を大雑把に分類すると、「仕様による脆弱性」と「実装による脆弱性」の二つにわけられるかな?
仕様による脆弱性
文字通り、実装で何とかできない脆弱性。それこそ「パスワードが4桁の数字」だとか「WEP」とか、そんなのね。これなんか実装で何とかしようとしてもなんともなんない。だから、仕様を決定するときに対策をとらなきゃいけない。
実装による脆弱性
いわゆる「XSS」とか「インジェクション系」とかの脆弱性。よく、セキュリティホールとして発見されるのがこっちかな?
これが発生する理由は、ぶっちゃけ「何を信頼し、何を信頼しないか」をはっきりさせておらず、「信頼できないもの」を利用するときには、「必ず」、「それが、信頼できる基準をみたしているか?」をチェックしていない、又は、「信頼できないもの」を「信頼できるようにする」方法を「漏れなく」実装していない為だと思う。
で、この脆弱性を対策するには、
-
- 信頼できるものと信頼できないものを明確にする。
- 信頼できないものはどういった条件で信頼できるかを明確にし、それを間違いなく実装する。
- 信頼できないものを信頼できるようにする方法を明確にし、それを間違いなく実装する。
必要があるかと。
基本的な考え方として、「信頼出来ないものは使わない」というものでないといけないんだけど･･･
そう考えると、コーディング時だけじゃなくて、設計時にセキュリティ対策を行う必要があるのは当たり前のように思うんだけどねぇ。
[追記]
これだと、「信頼できるもの」と「信頼できないもの」というのが分からんかw
「信頼できるもの」というのは「自分自身で生成したもの(外部のデータを変換して生成していないもの)」又は「自分でコントロールできる処理」。
「信頼できないもの」というのは「外部で生成されたもの」または「それから生成されたもの」、「自分でコントロールできない処理」。
という定義でいいかなぁ?
それより、「身内」を「信頼できるもの」、「よそ様」を「信頼できないもの」としてもイメージとしては分かりやすいかもw
[追記そにょに]
というか、ホスト系ってこういう考えが普通だったような。少なくとも、私が関った奴ではそうだったよ。初めてホスト計の開発の仕様書見たとき、何で入力チェックしてるのかわかんなかったしw
最近になって、理由が分かってきたよw
ホスト系の考え方が、Webアプリとか最近の考えでは普通じゃなくなってるんかなぁ?
