アーカイブ

月別アーカイブ: 7月 2005

6/29に第二回情報セキュリティEXPOの専門セミナーにてお話をさせていただく機会がありました。第一回のときは、OWASPの人とペアでしたので、「Webセキュリティ」の話一色でさせていただいたので、「フィッシングに利用されないようなサイト作りを」みたいなことを提言しました。今回は、アンチウィルスベンダーの方とペアで、どちらかというと企業がどのように防衛するか、という御題をいただきました。

Webにせよメールにせよ、セキュリティ防衛をする際に念頭におくべきことがあります。その一つは、「ネガティブポリシー(negative policy)」と「ポジティブポリシー(positive policy)」の違い。前者は、例えば「ブラックリスト」にのっとって受け入れられないものを排除する方式で、いうなれば悪いものをろ過する方式であり、前者と対照的に「ホワイトリスト」にのっとって受け入れられるものを厳密に定義する方式を解説しました。

ウィルス対策の場合、原理的に言ってウィルス定義ファイルはまさにブラックリストであり、それゆえにアップデートしつづけなければなりません。もちろん、ヒューリスティック検知方式などで補完することにより、ブラックリストに載っていないものも「それっぽい」ということで濾過することを可能にしています。SPAM対策でよく用いられる、ベイズ理論は、悪いものと良いものの両方の類推方法を学習していきますので、これら二つの方式の組み合わせと考えることができるでしょう。

WEBのフォームの入力データの場合、よく「サニタイズ(sanitize:「消毒」の意)」という言葉が用いられます。これは、ネガティブポリシーに基づく用語です。HTMLのタグや特殊記号などをフィルタリングするなり、クォーティングするなりという処理を行なうことを指します。しかし問題は、実際には入力データはそのアプリケーションの要件により毒にもなれば実にもなるわけですから、サニタイズという概念では完結しません。

また、危険の可能性がある文字なりパターンなりのすべてをプログラマーが知らない場合はどうでしょうか。見落としリスクがあるということです。そのアプリケーションは、そのプログラマーの腕に依存します。新たな脅威がでてきたら、そのプログラマーは直ちにサニタイズプログラムをアップデートしなければならないでしょう。それは現実的な方法ではありません。そういうわけで、WASForumのコンファレンスで高木さんが「サニタイズ排除キャンペーン」を発表されたのには全く同意です。

むしろ、正しいアプリケーション設計の観点から言うなら、本来すべきことはサニタイズではなく、入力の有効性検証(input validation)です。これはサニタイズに似ているようでも、実際には全く異なります。害のないデータでも無効なものはいくらでもあります。各々のフォームにおいて、「有効な(valid)」データを、桁数、文字種などに至るまできちんと定義し、そうでないものをすべて排除するという方式をとることです。

現場では、ポジティブリストの安全性を担保するため、あるいは、どんなリスクがすでに発生しているかを知るため、ブラックリストに該当する入力があった際にアラートを発生させるなどの方策を実装する場合などには、サニタイズプログラムは有効でしょう。しかし、根本的に、危険の可能性を知っていることだけを前提にした設計は、運用的にすぐに破綻しやすい、ということです。

今回の講演でこの話をしましたら、熱心に聴いてくださったメディアの方がサマリーを掲載してくださっていました。少しニュアンスが異なる部分もなきにしもあらずなのですが、シェイプアップしてサマライズしてくださっていますので、ぜひご覧ください。ご意見、ご感想も歓迎します。