補足
この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）備忘のため転載いたしますが、この記事は2008年7月22日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。
なお、この記事を書いた後、WAFはこの記事の予言（願い?）通りに進展したように思います。そのあたりの歴史については、こちらのインタビュー記事を参照下さい。
補足終わり
PCIデータセキュリティ基準(PCIDSS)がWAF(Web Application Firewall)について言及していることなどから、最近再びWAFへの関心が高まっている。一方、WAFは、一部のユーザや専門家に非常に評判が悪い。なぜ、そのようなことになるのか。本稿では、WAFの基本機能を説明した上で、その限界と運用上の問題を指摘し、今後のWAFの使い方について私見を述べる。
今回とりあげるWAFの基本機能は、以下の三種類である。
- 入力値検査
- 画面遷移のチェック
- hiddenフィールド操作の防止
WAFの機能(1)入力値検査
すべてのWAFの備える基本機能は入力値検査である。これは、パラメタ(クエリストリング、POSTパラメタ、Cookieなど)に対するホワイトリストあるいはブラックリストによる検査を行うものだ *1。SQLインジェクションやXSSなどインジェクション系の脆弱性対策は、この入力値検査が基本となる。入力値検査-ホワイトリスト検査
IPS(Intrusion Prevention System)が基本的にブラックリスト検査のみであるのに対して、WAFがホワイトリスト検査もできることは、WAFの特徴といえるだろう。ホワイトリスト検査は、Webアプリケーションの入力パラメタ一つ一つに対して、取りうる値の集合を正規表現などで定義し、検査の結果取り得る値から外れていたらリクエストをブロックするというものだ。前述のIPSに対するWAFの「優位」としてベンダーが大々的に宣伝することが多いのがこれだが、実際のサイトに適用するとなると以下のように問題が多い。- ホワイトリスト検査が可能なパラメタは限られている
- ホワイトリスト検査の対象パラメタと検査内容は個別に指定する必要があり煩雑である
- ホワイトリスト検査は本来アプリケーションで行うべきもの
- ユーザビリティの低下を招く可能性
ホワイトリスト検査が可能なパラメタは限られている
ホワイトリスト検査が可能なパラメタは、数値や英字など特定の文字種のみを受け入れるパラメータに限られる。具体的には郵便番号、電話番号、クレジットカード番号、ユーザID、メールアドレスなどだ。これら以外の自由記述形式のパラメタに対してはホワイトリスト検査はできない。ホワイトリスト検査の対象パラメタと検査内容は個別に指定する必要があり煩雑である
前のところで説明したようにホワイトリスト検査可能なパラメタは限られており、かつパラメタ毎に文字種や文字列長などが異なっている。このため、WAFの機能として、URLごとのパラメタを列挙した上で、パラメタ毎に検査方法を定義できるようになっている場合が多い。中規模以上のWebアプリケーションには膨大な数のパラメタがあるため、この設定はかなり煩雑となる。また、パラメタ毎の文字種などの仕様書があればよいが、なければアプリケーションをリバースエンジニアリングの手法で調べた上でWAFの設定を行う必要がある。文字種の制限が仕様書に記載されていることは期待できない。なぜなら、仕様書に書いてあるくらいならアプリケーション側で文字種チェックが実装されているはずであり、わざわざ手間を掛けてWAF側で設定する必要はないからだ。
最近の高機能WAFは「学習機能」と称してホワイトリストの自動設定ができるとうたっている場合が多いが、私の経験および見聞きした範囲では、学習機能がうまく動いて設定が自動化できたという話は聞いたことがない。最終的には人手によるチェックと修正が必要と考えた方がよいだろう。
ホワイトリスト検査は本来アプリケーションで行うべきもの
先にも少し触れたように、ホワイトリスト検査は本来アプリケーション側で行うべきものだ。郵便番号欄を例に説明すると、3桁および4桁の入力欄を用意して、数値以外の文字が入力されていればエラー表示して再入力を促すことになる。それくらいはアプリケーション側でやるべきだし、WAFでチェックすると後述のようにユーザビリティ的に問題となる可能性が高いこのように書くと、いやWAFで検査するのはラジオボタンなど選択式の入力欄に想定外の文字が入っている場合が主であって、郵便番号はアプリケーション側の検査でよく、この使い方であればユーザビリティ上の問題はないという反論がくるかもしれない。しかし今度は、ホワイトリスト検査が可能なパラメタのうち、どれがアプリケーションでの検査、どれがWAFでの検査とするかを詳細に調べ上げなければならない。これを学習機能で自動することは相当難しいだろう。というわけで、人手で設定するのは面倒だし、自動化には困難が伴う。
ユーザビリティの低下を招く可能性
前に書いたことと関連するが、ユーザの誤入力がWAFのホワイトリスト検査に引っかかった場合、ユーザに適切なナビゲーションを提供することは難しいだろう。そのためにユーザビリティが低下する可能性がある。入力値検査-ブラックリスト検査
Webアプリケーションのパラメタのうち、ホワイトリスト検査ができない（しない）パラメタについてはブラックリスト検査をすることになる。この場合のブラックリスト検査の目的は、「アプリケーション要件としては禁止されていないが、脆弱性に対する攻撃(SQLインジェクションなど)が疑わしい入力をブロックする」ことになる。このため、ブラックリスト検査は、過剰検知と検知漏れの両方のリスクがある。過剰検知の問題
ここでいう過剰検知(False Positive)とは、実際には攻撃目的の入力ではないのに、WAF攻撃とみなしてリクエストをブロックする場合を指す。Webアプリケーションの場合、アプリケーション要件的に禁止されていないものをブロックする*2わけだがら、ユーザにとっては不満の原因になる可能性が高い。検知漏れの場合
検知漏れ(False Negative)とは、実際には攻撃を受けているにもかかわらず、見逃してリクエストを受け付ける場合を指す。すべての攻撃パターンを正規表現などで表現することは元々不可能であるし、検知漏れを少なくしようとすると、今度は過剰検知が増えるという結果になる。ネガティブか、ポジティブか……それが問題だというわけで、LAC川口氏のコラムを引用させていただくことになるわけだが、脆弱性スキャナやIDSなど検査・監視系ツールの場合と異なり、過剰検知はユーザの実行を妨げ、ユーザビリティの低下に直結するため、少し緩めの(ブラック側に倒した)ルールにせざるを得ない。
そもそも入力時点検査での対応では無理がある - サニタイズ言うな
ここまで、ホワイトリスト検査とブラックリスト検査の特徴を説明してきた。ホワイトリスト検査は設定の手間が掛かることと、すべてのパラメタに適用可能ではない。ブラックリスト検査は過剰検知や検知漏れの可能性があり、総合的に判断して、入力値検査で完全な脆弱性対策とするのは無理がある。これは、セキュアWebアプリケーション開発の方法論としては既に結論が出た内容であって、XSSにせよ、SQLインジェクションにせよ、入力時ではなく、出力時(その値を使う時)に適切なエスケープなどにより対策すべき問題であるのに対して、WAFは出力時対応ができないからだ。言い換えれば、WAFはサニタイズ方法論で対応するものであって、元々限界があるのだ。WAFの機能(2)画面遷移のチェック
すべてのWAFが備えているわけではないが、商用WAFの多くが、なんらかの画面遷移のチェック機能を持っている。これは、大きく分けて二種類あり、(1)外部からの入り口となるページをチェックする、(2)Webアプリケーション内の全ての遷移をチェックする、という方法がある。
一見よさそうだが、このようなアプリケーションの場合、そもそも認証機能が正しく動いている限り、ログインページ以外には外部から遷移できないのであり、もしログインしていないユーザが遷移できたとすればそれは認証機能の重大な脆弱性である。脆弱性があるからWAFを導入するんだろうという突っ込みは予想できるが、こんな重要かつ基本的なところでWAFに頼らないと認証が正しく動かないのは問題であって、もし脆弱性があるならばWAFに頼らずに修正するしかないだろう。
一方、XSSやCSRFなど受動的攻撃への対策として、既にログインしている正規ユーザが外部から強制的に遷移させられるのを防止するという観点であれば、この機能に意味がある
内部画面遷移をチェックするのも多大な労力が必要
画面遷移のチェック機能として、Webアプリケーション内部の遷移(狭義の画面遷移)をチェックできるものがある。そのためには、まず正しい画面遷移をホワイトリストとしてWAFに定義する必要がある。私は、コンサルタントとして非常に多くのWebサイトの検査に携わってきたが、画面遷移図がドキュメントとして完備しているサイトがそもそも少なく、タイムリーにアップデートされているサイトは皆無といってよかった。しかも、アップデートされた画面遷移図があったとしても、通常全ての遷移を網羅しているわけではなく、例外的な遷移(エラー時など)までは記述していないと思う。その理由は、例外的な遷移まで画面遷移図に書いていくと、非常に読みにくいものになってしまうからだ。仮に完璧な画面遷移図があっとしても、それをWAFに設定することは大変な労力であるし、Webアプリケーションの保守作業のたびにWAF側の設定をアップデートしないと、更新された機能が動かなくなる。このような理由から、画面遷移のチェック機能は、現実には使われないケースが多い*3。
WAFの機能(3)hiddenフィールド操作の防止
これもすべてのWAFが備えているわけではないが、商用WAFの多くが備えている機能として、いわゆる「hiddenフィード改ざん」の検知とブロックがある。すなわち、hiddenフィールドやCookie、ラジオボタンなどの選択肢の値がクライアント側で改変されてないかチェックし、改変されていたらエラーとするものである。この機能の実装方式としては、私の知る限り二種類ある。一つは、hiddenフィールドやCookieの値を暗号化して改変できなくする、あるいはハッシュ技術により、改変されたことを検知・ブロックすると言うものだ。この実装方式は、クライアント側のJavaScriptと相性が悪いことが多く、暗号化あるいはハッシュ値が付与された値をJavaScriptで正しく読み込みできなくなる場合がある。
もう一つの実装方式は、WAF側でセッション管理を行い、hiddenの元の値を覚えておき、ブラウザからのリクエストとWAF側で記録した値とを比較するというものだ。一見よさそうな機能だが、ユーザが戻るボタンを操作すると、WAFで覚えている値とhiddenの値の食い違いが発生しそうだ。前述の画面遷移チェックと組み合わせて使うとよいのかもしれないが、設定が大変なためお勧めできない。
また、最近のWebアプリケーションでは、JavaScriptによりHTMLの内容をダイナミックに書き換えることが普通になっているわけだから、hiddenの書き換えをブロックこと自体が、Webアプリケーションの進化の方向とは衝突するものであるように思う。
WAFの三重苦とはなにか
ここで、WAFの三重苦とは何かを説明しよう。大半の商用WAFがホワイトリスト方式を標榜しているが、そもそもホワイトリストというものは、予め正しい内容を設定しておく必要があり、その元となる正しい仕様書がないからアプリケーション側の作りこみがもれるのだ。その肝心なところを直視しないでWAFに頼ろうとするユーザは、WAF購入後にたちまち現実に直面するし、WAF(最近はワフというらしいが)に対する不満を募らせることになるのだ。WAFが安いものであればまだしも、非常に高価な製品であるだけになおさらだ。というわけで、WAFの三重苦とは、こうだ。
割高で あてにならぬも 負担増
なんだか、はてなハイクのようになってしまったが、高価で、設定に手間が掛る割には、これで万全と言うものではないということだ。
三重苦を乗り越えWAFが普及するための私見
ここで、まとめとしてWAFに関する私見を述べよう。まず、WAFはホワイトリスト方式であるという主張はやめた方がよい。そんな主張をするから誤解を招くのだ。ホワイトリストの元となる正しい仕様は、仕様書に書いてないといけないし、仕様書に書いてあることはアプリケーションとして実装しなければならないのだ。だとすれば、WAFとアプリケーションでホワイトリスト検査の二度手間をやることになってしまう。
一方、WAFのブラックリスト検査については、私は元々懐疑的だったが、その考えが少し変わってきた。「サニタイズ言うな」に基づく現代的なセキュアWebアプリケーション開発では、アプリケーション側ではブラックリスト検査をしない。だから、WAFとアプリケーションとで検査の重複はなくなるのだ。実運用に影響を与えない程度の控えめなブラックリストをチューニングして、それを全パラメータ共通で使用する。そうすれば、手間も掛らないし、機械化されたSQLインジェクション攻撃程度であれば十分な効力がある。それでも運用に影響が出るパラメタもある(ブログや掲示板など)が、そのパラメタだけはブラックリスト検査を除外して、その代わりしっかり脆弱性検査をして対策もアプリ側でとっておけばよい。
Webアプリケーションの脆弱性対策は、アプリケーションの作りこみで行うべきであるが、アプリケーションが大規模になるほど対策漏れの可能性は大きくなる。上記のようなWAFの運用であれば、アプリ側の対策漏れに対するセーフティネットとして働くことが期待できる。その理由は、WAFの細かい設定をしないからであり、WAFの細かい設定をすればするほど、WAF自体の設定漏れを心配しなければならなくなる。それは本末転倒であって、WAFに対して割り切った使い方をした方がかえって安全ともいえる。
また、WAFの低価格化は必須だ・・・というより、ホワイトリスト機能を使わないのであれば、安いWAFで十分だ。そうすると、割高、負担増の二重苦が消え、残りは「あてにならない」だけが残るが、セキュリティ製品なんてファイアウォール、IPS、ウィルス対策ソフト・・・いずれをとっても「あてになる」ものはないのだから、WAFにだけ完璧を期するわけにもいくまい。ブラックリストでの防御という点ではIPSと機能がかぶるが、ことWebアプリケーションの脆弱性に関しては、ブラックリスト機能だけ使ってもWAFのほうが検知能力が高い。ここに、WAFの存在価値が見出せると私は考える。
最後に控えめな宣伝を。WAFの選定・導入に関する相談はこちらまで。
参考:ITproに書いたWAFの評価・比較レポートです WAFでWebアプリの脆弱性を守れるか：ITpro
2009/10/26追記
KCCSにて、10月29日（木曜）、11月26日（木曜）、12月17日（木曜）の3回にわたり、WAFのセミナーを実施することになりましたので、興味のある方は、こちらのリンク（アーカイブ）から内容確認の上お申し込みください。*1 ホワイトリストとブラックリストについては、ホワイトリスト方式の優位は神話を参照されたい
*2 アプリケーション要件として禁止されているならホワイトリスト検査が可能だ
*3 これについては、WAFベンダーからも次のような証言がある。
APC Phase 2が最もセキュリティの高いものであることはいうまでもないが、すべてのページ遷移パターンまでもWAFに登録せねばならない。そうなると初期設定に相当の時間がかかり、運用開始後のコンテンツ変更時にも相当の労力と時間を要する。事実、BIG-IP ASMを採用している顧客の中でも、APC Phase 2を利用している顧客は、極めてコンテンツ変更の頻度が少ない数社しか存在しない。
WAFのセキュリティレベルとパラメータ設定より引用
6 件のコメント:
□ AzureStone (2008年07月23日 09:11)初めましてAzureStoneです。記事を読みました。WAFは、実際にお使いになられたことはあります？
□ 徳丸浩(ockeghem) (2008年07月23日 09:56)
AzureStoneさん、こんにちは
私が使ったものと言っても、実際には私が指揮して、私自身が手を動かしてないものも含まれますが、以下はお客様に導入したものと実機で評価したものです。
AppShield
InterDo
Teros (現Citrix)
NetContinuum (現Barracuda)
SecureSphere Imperva
F-Secure Site Guard
ですね。こうしてみると、なくなったり、買収されたものが多いなぁ。メジャーなところでは、F5 BIG-IPは使ったことがありません。
□ AzureStone (2008年07月23日 10:06)
> 私自身が手を動かしてないものも含まれますが
あっ、なるほど。
ぐ、ぐぐ、具体的な製品名ありがとうございます。。
ちょっと驚きました。
NetContinuum (現Barracuda) とF-Secure Site Guard は、
ホワイトリスト・ブラックリスト両方いけますよ。
パターンパッチは、SiteGuardの方が種類が豊富でNetContinuum (現Barracuda)と比べて誤検知が少なかったです。
□ AzureStone (2008年07月23日 10:08)
F-Secure Site Guardは、買収ではなく業務移管するようです。
□ まっちゃだいふく (2009年09月04日 11:02)
誰がWAFのお金を出すか、そこも合わせて考えないといけない時期ですね。
■新規構築時
開発にて設計上必要と考慮して購入
→ 開発費用として計上
■運用上時に問題として発覚時
運用チームにて予算計上して購入
→ 通りにくい運用の予算計上
現実、今のWAFの興味を持っている人が後者なので、予算的にきびいいのかなぁ、って思います。
□ トムヤン (2010年03月19日 14:52)
最近、ＷＡＦ製品の販売をしてまして、このサイト大変勉強になりました。おっしゃられたブラックリスト・ホワイトリストは運用や設定が手間と聞いていたので、ルールベース型ＷＡＦの「WAPPLES（ワップル）」をかついで販売をしようと思っています。もし、このへんの情報があれば教えてください。
0 件のコメント:
コメントを投稿