“完璧なWAF”に学ぶWAFの防御戦略
セキュリティExpert 2010
クロスサイト・スクリプティング(XSS)に対する防御
大河内氏の寄稿の前半は、現状のWAFの課題として、Webアプリケーションに対する攻撃の多く（大半）がWAFのデフォルト設定では防御できないと指摘する。例えばクロスサイト・スクリプティング(XSS)に関しては、以下のような指摘がある。
仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか？プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。
「現状の課題と“完璧なWAF”」より引用
「<IMG>タグでXSSが発動」が具体的にどのようなパターンを指すのか曖昧だが、XSS Cheat SheetにはIMG要素によるXSSがいくつか紹介されているので、このようなパターンを指しているのかもしれない。
<IMG SRC="javascript:alert('XSS');">
<IMG SRC=javascript:alert('XSS')>
<IMG SRC=JaVaScRiPt:alert('XSS')>
<IMG SRC=javascript:alert("XSS")>
<IMG SRC=`javascript:alert("RSnake says, 'XSS'")`>
<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>
<IMG SRC=javascript:alert('XSS')>
<IMG SRC=javascript:alert('XSS')>
<IMG SRC=javascript:alert('XSS')>
<IMG SRC="jav ascript:alert('XSS');">
<IMG SRC="jav	ascript:alert('XSS');">
<IMG SRC="jav
ascript:alert('XSS');">
<IMG SRC="jav
ascript:alert('XSS');">
【略】
一見複雑に見えるが、ほとんどのパターンはjavascript:という擬似スキームそのものや、これに難読化を施したものであるので、そのような手がかりを元にシグネチャを構成できる。しかも、XSS Cheat Sheet自体が業界で有名なドキュメントなので、WAF制作者たるもの、ここに載っているパターンくらいは対策すると考えるのが自然だろう。私がかつてWAFを評価した際にも、ここに出てくるパターンを試したところ期待通りにブロックしてくれていた。
大河内氏の文章には前提条件が書かれていないのでコメントしにくい。例えば、安全なウェブサイトの作り方には、「HTMLテキストの入力を許可する場合の対策」という項があるが、そのようなケースではWAFによる防御は難しい。大河内氏の意図が、IMG要素そのものをユーザが入力するケースを想定しているのであれば、「HTMLテキストの入力を許可する場合」に該当する。しかし、HTMLテキストを許可するアプリケーションは一部のブログや掲示板など特殊なアプリケーションなので、WAFがこれらに対応できないからと言って、WAFがダメダメだと主張するのも酷だろう。それに、IMG要素を使ったXSSにWAFは対応しているわけなので、「<IMG>タグは画像添付に必須であり、WAFで禁止することは難しい」という書き方はおおざっぱに過ぎ、適切な表現とはいえないだろう*1。
SQLインジェクションに対する防御
次にSQLインジェクションに関する説明を読んでみよう。
SQLインジェクション対応の駄目な例として挙げられるのは、複文などの直接攻撃しか考慮していないケースです。簡単に言うと、master..execなどの直接攻撃のみ禁止しているWAFは甘く、union selectなどのunionインジェクションを考慮したWAFはまだマシであると言えます（攻撃者の観点が分かっているという意図でマシと記載しました）。
このブラックリストを通り抜けるにはコメントを使用します。たとえば、union/**/selectではどうなるでしょうか? 残念ながらほとんどのWAFは通り抜けてしまいます。
「現状の課題と“完璧なWAF”」より引用
「master..execなどの直接攻撃のみ禁止しているWAFは甘く」という興味深い記述があるが、私は寡聞にしてそのようなWAFを知らない。ぜひどこの何というWAFが該当するのか教えていただきたい。
また、unionインジェクションに関する記述も興味深い。私がかつて評価したWAFは全てunionインジェクションをブロックしたが、「union select」という並びだけでブロックするWAFは、F5 BIG-IPとImperva SecureSphereだけだった*2。残りの
Citrix Application Firewall、Barracuda Web Application Firewall、JP-Secure SiteGuardの三製品は、「union select」という並びが入力にあってもブロックしない。
一方、「union/**/select」という並びでは、BarracudaおよびSiteGuardはブロックするのだ*3。
「union select」だけだとブロックしないが、「union/**/select」だとブロックする。これは、過剰検知(False Positive)対策だろうと思う。unionやselectは非常に基本的な英単語なので、これを単純にブロックしてしまうと、ユーザの正常な入力もブロックする恐れがある。例えば以下のような文はどうか。
G.M. union select the choice.
selectではなくて（三単現の）selectsじゃないのかというツッコミはご容赦いただくとして、上記のような英文を攻撃と誤検知すると運用に支障が出る。そこで、現代的なWAFは単純なunion selectの並びだけではなく、前後の文脈を考慮してSQLインジェクションとして成立するかどうかを判定するように進化しているのだ。このようなWAFは、「union select」だけならブロックしないが、「union select hoge, fuga, null, 1 from usermaster」ならブロックする*4。そして、どこまでならスルーし、どこからならブロックするかの境界は過剰検知との兼ね合いのさじ加減で決まってくるので、WAFベンダーのシグネチャ作成者が苦心して決めていると推測する。
一方、union/**/selectの方は、一般の英文として出てくることはまずないだろうし、SQLインジェクションの難読化とみなすことができるので、多くのWAFがブロックする。
つまり、「union selectならブロックするが、union/**/selectはほとんどのWAFは通り抜ける」という大河内氏の主張はWAFの現状を反映しておらず、むしろ「union selectは（わざと）通すがunion/**/selectはブロックする」がWAFの現状としては正しい。大河内氏は「ほとんどのWAFは通り抜ける」と断定するのであれば、具体的にどのWAFがそうなのかを示す責任があるだろう。
クロスサイト・リクエスト・フォージェリ(CSRF)に対する防御
CSRFに関して大河内氏は以下のように記述しておられる。
ではWAFでは何が防げないでしょうか。まずクロスサイトリクエストフォージェリは、ユーザが意図しない行動を起こしてしまうものであり、リクエスト自体は正常なリクエストとして扱われ処理されます。つまり、ユーザが意図しないだけであって、リクエスト自体には問題はありません。こういった攻撃はWAFでは防御できないのです。
「現状の課題と“完璧なWAF”」より引用
こういう大ざっぱな議論をしてしまうと、XSSやSQLインジェクションだって「リクエスト自体には問題は」なく、WAFで防御できないことになってしまう。それはともかく、CSRFがWAFで防御できないという状況は、以下のどの状況を指しているのだろうか。
大河内氏の書き方だと、CSRFは原理的にWAFでは防御できない、すなわち(a)パターンのように読めるが、それは誤りだ。
金床氏の著書「ウェブアプリケーションセキュリティ
クロスサイトスクリプティングやSQLインジェクションと異なり、CSRFはWAFで確実な対策を行うことが可能だ。ここでは WAF(Guardian@JUMPERZ.NET)を用いたCSRF対策について具体的に説明する。
この記述に続いて、Guardian@JUMPERZ.NETのCSRF防御戦略と設定方法が説明されている。それは、Webページにトークンを自動的に埋め込んで、フォームの受け取り側でチェックするというものだ。トークンをチェックするページは明示する必要があり、設定は少々面倒となる。このため、上記の分類では(c)となる。また、トークン利用の他、Refererをチェックする方式でも実装は可能だろうが、私はそのようなWAFを見たことはない*5。
大河内氏はおそらく金床本を読んでおられないのだろう。日本でWAFビジネスをされるのであれば、金床本くらいは一度目を通しておかれることをお勧めしたい。
アクセス制御不備に対する防御
アクセス制御（認可）の問題については、大河内氏は以下のように記述しておられる。
アクセス制限の不備もWAFには判別不可能です。たとえば管理者ページを認証機構なし設置し、単にそのほかのページからリンクしていないだけ、というケースを考えてみましょう。この場合、URLを知っている者のみがアクセス可能ですが、それが容易に思いつくものか思いつかないものか、いずれであってもWAFには通常のWebページと区別できないため防御できません。
「現状の課題と“完璧なWAF”」より引用
この内容について検討してみよう。
アクセス制御（認可）の不備について、ウェブ健康診断仕様では以下の3種類の診断パターンを用意している。
- URL操作により、現在のユーザでは実行権限のない機能が実行可能
- 文書ID､注文番号、顧客番号等がパラメータにより指定されている場合、そのID 類を変更して、元々権限のない情報を閲覧できるか
- hidden, Cookie に現在権限が指定されており、その変更により現在のユーザでは実行権限のない機能が実行可能
大河内氏の指摘は、上記分類では(1)に該当する。しかし、現実のWAFには、ウェブ健康診断仕様で規定された認可不備のパターンを全て防御できるものが多い。当然ながら、大河内氏の指摘したパターンも防御できる。
この種の防御がもっとも得意なWAFは、Citrix Application Firewallであろう。Citrixの場合は、セッション毎に「次に遷移して良いURLの集合」を管理していて、A要素やフォームのアクション属性などにより参照されていないURLに遷移するとエラーにする(ブロックする)ことができる。これは(1)に対する防御として有効だ。また、CookieやHiddenフィールドに対する保護機能があるので、(2)や(3)に対する攻撃を検知し、ブロックすることができる。Citrixの他、JP-Secure SiteGuardなどもこれらの機能をもつ。下図に、SiteGuardの設定画面を引用する。下図で、「URL遷移検査」というのが上記(1)に対する防御、「フォーム変数検査」が(2)および(3)に対する防御となる。ただし、Cookieに関してはこの設定では保護されないので、「Cookie暗号化」という機能で防御することになる*6。
このように、WAFには典型的な認可不備に対する防御機構が用意されている。したがって、「WAFには通常のWebページと区別できないため防御できません」という指摘は誤りだ。
もっとも、認可処理はセキュリティ機能の根幹といえる部分であるため、アプリケーションの認可機能に欠陥を残したままWAFだけの防御で運用することは不安だという議論はあるだろう。また、認可不備は上記3パターンだけでなく色々なバリエーションがあるので、WAFで常に防御できるわけではない。しかし、それならそのように表現すれば良いだけの話で、WAFが原理的に認可不備を防御できないような表現は誤りだ。
チューニングについて
大河内氏の寄稿の後半は、“完璧なWAF”を実現するチューニングの話題に移るのだが、このチューニングの部分もかなりユニークだ。氏は、初期状態のWAFは非常に不完全な状態で、チューニングにより完全な状態にする必要があると指摘する。
WAFの初期状態（いわゆる最低限のブラックリストのみ）ではおおよそ50%程度の数値であると表現できます。チューニングをすることで60〜70%まで上げることができるでしょう。チューニングをきつくすると、120%となりサイトの機能が一部動作しなくなります。では、残りの30〜40%のみ上げるにはどうすればいいのでしょうか。
筆者は検知システムと同様、WAF+チューニング+サービスで100%に限りなく近づけることができると考えています(図3)。
図3●適切なシグネチャのチューニングとサービスの連携により100％を目指す
「現状の課題と“完璧なWAF”」より引用
短い文章の中にユニークな視点がちりばめられている。以下検証する。
WAFの初期設定に対する考え方
図3によると、“完璧なWAF”は、購入当初ではFalse Negative（検知漏れ）気味に設定されていて、チューニングより検知率を高めるようになっている。一方、現在市販されているWAFには、購入当初はFalse Positive（過剰検知）になっていて、導入後のチューニングで過剰検知しているシグネチャを外すことにより適正な状態に設定できるようになっているものがある。F5 BIG-IPやImperva SecureSphereがそのような製品の例である。さらに、JP-Secure SiteGuardやBarracuda Web Application Firewallは、極力初期設定のままチューニングなしで使えるというコンセプトの製品である。先に紹介した「union select」の例がわかりやすい。F5とImpervaは「union select」をブロックするので、導入後の検証中に過剰検知が判明すれば、該当のシグネチャを外すわけである。一方、SiteGuardとBarracudaは、はじめから「union select」のように過剰検知しやすいシグネチャが設定されていないのだ。
私は、SiteGuardやBarracudaのようにチューニングの労力が少ない製品が好ましいと考えている。一方、“完璧なWAF”のように、初期状態で50%のできで、チューニングとサービスで100%にもっていくというコンセプトは斬新だ。
なぜチューニングシグネチャを初期シグネチャに含めないのか
ここで一つの疑問が生じる。後から追加するシグネチャは、最初からセットしておいては駄目なのか。大河内は、自社で開発したWAFを自社でチューニングするという前提で寄稿している。であれば、「チューニングシグネチャ」を「初期シグネチャ」に含んでしまえば、煩わしいチューニング作業が省略でき、導入コストも低減できることになる。
その理由として私が思いついた仮説を二つ紹介する。一つは、“完璧なWAF”は現在開発中なので当初は完成度が低く、チューニングと称して完成度を高めていくという仮説だ。しかし、この仮説はあまりにも顧客不在の考え方であって、おそらく違うのだろう。
もう一つは、「チューニングシグネチャ」は過剰検知が多く、初期シグネチャには加えられないものだという仮説だ。F5やImpervaは、このようなシグネチャも初期シグネチャとして加えておいて、チューニング時に削除するという考え方であるわけだが、“完璧なWAF”は、初期シグネチャには加えずに、チューニング時に追加するということらしい。だが、どうやって。
False Negativeをどうやって検知するのか
ここで生じる疑問は、False Negativeを検知する方法があるのかということだ。本寄稿のP99には以下のような記述があるのだが、
運用については、まず誤検知（False PositiveとFalse Negative）に対応できる自社監視チームや監視サービスが存在するかどうかがポイントです。
「現状の課題と“完璧なWAF”」より引用
False Positiveの方はWAFが検知しているから監視できるのは分かるが、False NegativeはWAFが検知していないので、監視しようがないのではないか*7。F5やImpervaが初期状態でFalse Positive方向に設定されているのは、WAF自体で誤検知を検知できるようにという配慮だろう。“完璧なWAF”が斬新だと思うのはこのような部分であって、WAFが検知していないFalse Negativeを検知できる特別な監視手法があるのかもしれない。まことに興味深い内容であり、“完璧なWAF”のリリースが待ち遠しい。
サービスで補うとは具体的にはどういう意味か
さらに、チューニングシグネチャでも防御できない30〜40%を補う「サービス」についても興味深い内容だ。しかし、そのサービスが具体的に何を指すのか、本寄稿を読んでもよくわからない。P99には以下のような記述もあるのだが、
WAFで守れない部分については、最大手ネット通販会社などで採用されているセキュリティ教育コンテンツの講師が、独自のノウハウを盛って指導を行う予定です。
「現状の課題と“完璧なWAF”」より引用
ここを読む限り、WAFで守れない部分はアプリケーション側で対策すべく、開発チームを教育してくれるということだろうか。しかし、これではWAFで守ったことにならないので、“完璧なWAF”と銘打つのは誇張が過ぎ、違うような気がする。さらに、先に引用した図3を見ると、第三段階ではサービスによる防御の割合が縮小し、チューニングシグネチャによる防御の割合が大幅に増えている。これは本文中でも、
こうしたポイントに加え、監視チームやアプリ開発社からのフィードバックを受けてチューニングを継続していくうちに、100%に近づくチューニングを実施できるのです。
「現状の課題と“完璧なWAF”」より引用
とあるので、なにか特別な「サービス」があるのかもしれない。仮に、開発者が教育を受けてアプリケーション側で対策ずみなのであれば、わざわざWAF側でチューニングして（当然費用が発生する）対応する必要はまったくないからだ。
まとめ
大河内氏の“完璧なWAF”の寄稿をなぞる形で、WAFの防御戦略について検討した。前半の「WAFで防御できない攻撃」については若干の誤解もあるようだが、本論の“完璧なWAF”については、他に類を見ない極めてユニークな製品に仕上がる予定のようだ。大河内氏の文章がへたくそなためか、私の理解力が不足しているせいか、“完璧なWAF”の詳細についてはまだ不明な点が多い。製品リリースのあかつきには、是非詳しい内容を紹介していただきたい。
*1:元のタイトルが“完璧なWAF”となっているので、IMG要素も完璧な対応を求めているのかもしれない。だとすると、HTMLテキストの入力を許可するアプリケーションにも対応する“完璧なWAF”は驚くべき性能を持つことになる。はてなダイアリーは度々XSS脆弱性が指摘されているようだが、“完璧なWAF”を導入すれば解決するのだろうか
*3:Citrixについて未調査
*4:厳密には、SQLインジェクション攻撃が成立するためには、unionの前にシングルクォートか式が必要だ
*5:手動でルールを追加する方法であれば、多くのWAFで対応可能であると思われる
*6:デフォルトではいずれもオフになっていて、導入時に設定する必要がある
*7:False Negativeを調べる方法として、WAF越しに脆弱性診断をするという方法があるが、寄稿では触れられていない。このアプローチだと、網羅的に診断しないとFalse Negativeの洗い出しが出来ないので、コストはかなり高くなる。
