脆弱性の分類と脆弱性の原因

2006年11月18日(土曜日)

脆弱性の分類と脆弱性の原因

「Dreamweaver プロフェッショナル・スタイル (cssnite.jp)」という本が出ることになっておりまして、末尾の方には Dreamweaver とあんまり関係ない脆弱性関連の話が出てくるわけですが、脆弱性関係の文章を書いていていつも思うことがあります。

それは、脆弱性の分類がメチャクチャだということです。良く耳にする脆弱性の名前というものがあると思いますが (「クロスサイトスクリプティング」など)、それは「原因となった欠陥」だったり「攻撃手法」だったり「結果として起きたこと」だったりしていて、全くもって MECE な分類になっていないのです。

※MECE = Mutually Exclusive collectively Exhaustive で、「もれなく、重複無く」という程度の意味。

たとえば ACCS事件を見てみると、こんな感じになります。

原因 : CGI はパラメータをそのまま open() に渡していた (パス名パラメータの未チェック)
手法 : input type="hidden" に指定されていた ng_file というパラメータの値を変更して送信 (パラメータ改竄)
結果 : 別のディレクトリに置かれていた、外部からアクセスされてはならないはずのログファイルの内容が表示された (ディレクトリ・トラバーサル)

起きたことは一つなのですが、脆弱性の名前らしきものが 3つ出てきており、3つが同時に当てはまっています。つまり、これら 3つは排他的ではないということです。

こんな風に「原因」「手法」「結果」に分けて考えると分かりやすいのかな……と思うのですが、原因を考えていくとさらに深い問題があります。たとえば、こんなケースを考えてみます。

foo.cgi というデータを表示する CGI が存在する
foo.cgi?page=1 foo.cgi?page=2 などというパラメータを渡すと、適切なページが表示される
このとき、画面には「現在1ページ目」などと表示される
foo.cgi?page=1%3cscript%3e……などというパラメータを渡すと、スクリプトが実行されてしまう

手法は「パラメータ改竄」、結果は「クロスサイトスクリプティング」となりますが、「原因」について考えると……。

画面に文字列を表示するときに < などは文字参照に変換すべきだったが、その変換を怠っていた (エスケープ漏れ)
page= に数字以外の値が指定されたときにはエラーにするべきだったが、そのチェックを怠っていた (パラメータのチェック漏れ)

これらのうち、どちらか一つでもつぶせばクロスサイトスクリプティングは防げます。どちらの対応が良いのか、というのは難しい問題です。普通に考えると「数字でなければエラー」という対処のほうが良さそうに思えます。しかし純粋に「脆弱性を修正する」という観点だけで考えると、どちらの対策でも同じです。

もっと難しいのは設計に問題がある場合です。ACCS事件などは「パス名を適切にチェックしてエラーにする」という話以前に、「そもそも外部パラメータでファイル名を指定させること自体が問題」と思うわけです。後者の設計にこそ問題があると思うのですが、外部パラメータでファイル名を指定させることをやめると、仕様が大きく変わってしまいます。「脆弱性の修正」という枠に収まらなくなってしまいます。

もっと言うと「CGIを削除する」という対策だってあるわけです。そう考えると、どこまでが「脆弱性の原因」と呼べるものなのか、判断するのが難しいのではないかと思います。

「脆弱性の分類と脆弱性の原因」へのコメント (1件)

前(古い): 黒船
次(新しい): 脆弱性の視野