2008年7月16日水曜日

ホワイトリスト方式の優位は神話~ホワイトリストとブラックリスト~

補足

この記事は旧徳丸浩の日記からの転載です(元URLアーカイブはてなブックマーク1はてなブックマーク2
備忘のため転載いたしますが、この記事は2008年7月16日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。
なお、「ホワイトリスト」という用語の定義については、以下の記事の「第二種ホワイトリスト」に相当するとお考えください。この記事の投稿当時、ホワイトリストという用語の定義の揺れについては意識しておりませんでした。


補足終わり

近々WAF(Web Application Firewall)の話題を取り上げたいと思っている(→WAFの話題はこちら)。WAFの説明には決まってホワイトリストとブラックリストという用語が出てくる。しかし、WAFの宣伝やブログなどのエントリを読んでいると、ホワイトリストやブラックリストという言葉に対する誤解があるように見受けられる。そのため、WAFの話題の前に、この二つの用語の説明をしておきたいと思う。

ごく大雑把に言って、ホワイトリストは「怪しくない人・モノ」を列挙したもの、ブラックリストは「怪しい人・モノ」を列挙したものだ。これらのうち、日常生活でなじみのある用語はブラックリストだろう。クレジットカードの支払いを延滞すると「ブラックリスト」に名前が載り以降しばらくカードが作れなくなるとか、テロ組織のメンバーの名前が書かれた一覧表も「ブラックリスト」と呼ばれる。

最近話題の携帯コンテンツのフィルタリングについても「ホワイトリスト」方式と「ブラックリスト」方式の是非が議論された。この場合は、青少年の閲覧に問題ないサイトの一覧が「ホワイトリスト」、問題が想定されるサイトの一覧が「ブラックリスト」となる。

さて、問題はこの二つの方法論の使い分けだ。冒頭に述べたようにセキュリティ業界ではなにかとホワイトリストの人気が高いようだが、この傾向はWAF分野において顕著だ。以下は、とあるWAFの宣伝文句であるが、ホワイトリスト方式の利点が高らかにうたわれている。
・・・のWAF機能は、ポジティブ・セキュリティと呼ばれるホワイトリスト方式を採用している。これはポリシーによって正しいと定義されたトラフィックのみに、Webアプリケーションへのアクセスを許可する方式。不正アクセスをブラックリスト方式で識別するIDC(不正侵入検知システム)やIDP(不正侵入防御システム)では常にリストを更新する必要があるが、ホワイトリスト方式なら頻繁な更新は不要で、新しい攻撃に対する防御能力も高い。 引用元
一例のみ紹介したが、このような題材を探すには苦労しない。そして、そのような説明の多くが、ブラックリスト=古くて劣ったもの、ホワイトリスト=新しくて優れたもの、という調子だ。引用した文もそうなっているが、ホワイトリスト方式=ポジティブ、ブラックリスト方式=ネガティブという用語も(こう呼ぶ意味はあるのだが)ホワイトリスト方式の優位を印象付ける。

しかし、である。本当にホワイトリストが優れていて、ブラックリストが劣っているのであれば、法律かなにかでブラックリスト方式を禁止し、今後はホワイトリスト方式のみを採用するようにすべてのセキュリティベンダに強制すべきではないのか。現実にはそんなことはできないのであって、例えばウィルス対策ソフトをホワイトリスト方式で実装することは不可能だ。ホワイトリストとブラックリストにはそれぞれ長所と短所があって使い分けをすべきものであり、どちらが優れているとか劣っているというものではないのだ。

右の図はホワイトリストとブラックリストの位置づけを概念的に示したものだ。図のように、ホワイトリスト(WL)は「まず安全と考えられるもの」を列挙したもの、「ブラックリスト(BL)」は「安全でない可能性がかなりあるもの」を列挙したものとなる。そして、ホワイトリストとブラックリストのどちらにも載ってない中間部分が、「白黒はっきりしない中間領域」すなわちグレイゾーンとなる。

この図からもわかるようにWLとBLで示すことのできる領域は全体として一部であり、どうしてもグレイゾーンが大きくなる。すなわち、WLは判断を安全サイドに倒して「安全という保証のないものは全て排除する」もの、BLはカバー範囲を広くとることを重視して「明らかに怪しいもの以外は受け入れる」方法ということになる。この関係を以下に表として示した。


方式ホワイトリスト方式ブラックリスト方式
カバー範囲狭い広い
安全性高い危険なものを受け入れる可能性あり

これだけのことだ。ホワイトリスト方式の方が安全なことは確かだが、世の中全てホワイトリストで回せるはずがない。セキュリティの世界では守るべき対象の性質によってはホワイトリストが使える場合があって、その場合はぜひホワイトリストにしなさいというだけのことである。前述のように、ホワイトリストが使えない場合が現実には大半なので、(問題があるとは分かっていて仕方なく)ブラックリスト方式を使う。それだけのことだ。特に方法論自体の優劣とは関係ない。

ついでのように紹介して恐縮だが、大垣さんの書かれたホワイトリストはどう作る?は、ホワイトリスト神話の悪しき例と言わざるを得ない。
スクリプトインジェクション(XSS)防止にブラックリストが機能しない事は明らかです。ホワイトリストはどう作れば良いか参考となるリンクです。どう作るか書いておいても古くなる可能性が高いので、どこを参考に作れば良いか参考URLを書いておきます。
以下のリンクの情報からスクリプトのインジェクションがどのように行えるかを参考にホワイトリストを作れば概ね間違いないと思います。

Follow up:
XSS Cheat Sheet
http://ha.ckers.org/xss.html

スクリプトインジェクション手法の中でも有名な手法を集めているサイトです。XSSロケータと呼ばれている文字列はスクリプトインジェクション脆弱性検出に重宝します。よくある脆弱性であればこの文字列で簡単に検出できます。
[ホワイトリストはどう作る?より引用]
大垣さん、これではホワイトリストではなくて、ブラックリストそのものです。
一方、興味深いことに、金床さんの書かれたウェブアプリケーションセキュリティには、同じ題材を取り扱っているが、その記述はまるで異なる。
WAFを使用しブラックリスト方式のシグネチャマッチングによってXSS対策を行う場合、攻撃を完全に防ぐことは不可能である。これはXSSを引き起こす可能性のある文字列が非常に多岐にわたるためだ。このことは非常によく知られたドキュメントであるXSS Cheat Sheetを見るとよくわかる。【中略】望ましい対策として、パラメータごとにホワイトリスト式のチェックを行う方法が考えられるが、残念ながら多くのウェブアプリケーションではホワイトリストをきちんと定義することが難しい【中略】従って、WAFを使ってXSS攻撃を完璧に防ぐことは期待できない。
[ウェブアプリケーションセキュリティ(P92~P94)より引用]
同書の書評でも述べたが、オープンソースのWAFの開発者としてホワイトリストとブラックリストの両方に真剣に向き合ってきたからこそ書ける、正確かつ誠実な記述である。

金床さんのWAFの話題が出たところで、次回はWAFの説明に続く・・・そろそろWAFに関して一言いっとくか~三重苦を乗り越えてWAFが普及するための条件とは~



1 件のコメント:

_ yohgaki (2008年08月20日 16:50)
大垣です。手抜きエントリを見事に誤解されたので追記しました。
http://blog.ohgaki.net/-7

それから、ホワイトリスト方式とブラックリスト方式の考え方は私の考えとは大きく異なります。ホワイトリスト型、ブラックリスト型のセキュリティ対策では分かり辛いように思えるので個人的には能動的(プロアクティブ)と受動的(リアクティブ)なセキュリティ対策と言う方が好みですが、バッファーオーバーフローをバッファーオーバランと言うような物なのでホワイトリスト型、ブラックリスト型の対策として書いています。
http://blog.ohgaki.net/-13

ところでXSS Cheat Sheetは読まれましたか? アレを読んでそれでもブラックリスト方式でXSSを防げる、と信じられる方はかなりの重症だと思います。なので、読まれていないと思います。あのエントリはホワイトリストを自分で作る事を考えてもらえるように書いています。XSS Cheat Sheetを読まないと意味がありません。

0 件のコメント:

コメントを投稿

フォロワー