水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 脆弱性の分類と脆弱性の原因

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

2006年11月18日(土曜日)

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

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

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

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

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

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

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

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

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

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

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

関連する話題: Web / セキュリティ / 思ったこと / クロスサイトスクリプティング脆弱性 / Dreamweaver

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーションウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト