Hatena::ブログ(Diary)

ockeghem(徳丸浩)の日記 このページをアンテナに追加 RSSフィード

[PR]WAFの導入はHASHコンサルティング
 | 

2010-05-07

“完璧なWAF”に学ぶWAFの防御戦略 “完璧なWAF”に学ぶWAFの防御戦略を含むブックマーク

セキュリティExpert 2010に大河内智秀氏が「現状の課題と“完璧なWAF”」と題して寄稿されている。大変興味深い内容であるので、この寄稿をなぞりながら、WAFの防御戦略について検討してみたい。

クロスサイト・スクリプティング(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(&quot;XSS&quot;)>
<IMG SRC=`javascript:alert("RSnake says, 'XSS'")`>
<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>
<IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>
<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>
<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>
<IMG SRC="jav ascript:alert('XSS');">
<IMG SRC="jav&#x09;ascript:alert('XSS');">
<IMG SRC="jav&#x0A;ascript:alert('XSS');">
<IMG SRC="jav&#x0D;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”」より引用

こういう大ざっぱな議論をしてしまうと、XSSSQLインジェクションだって「リクエスト自体には問題は」なく、WAFで防御できないことになってしまう。それはともかく、CSRFがWAFで防御できないという状況は、以下のどの状況を指しているのだろうか。

  1. 原理的にWAFで防御できないことが証明されている
  2. まだ有効な防御アルゴリズムが発見されていない
  3. 有効なアルゴリズムがあり一部のWAFでは実装されているが設定・運用が大変なので普及していない
  4. その他

大河内氏の書き方だと、CSRFは原理的にWAFでは防御できない、すなわち(a)パターンのように読めるが、それは誤りだ。

金床氏の著書「ウェブアプリケーションセキュリティ」のP119には以下のような記述がある。

クロスサイトスクリプティングSQLインジェクションと異なり、CSRFはWAFで確実な対策を行うことが可能だ。ここでは WAF(Guardian@JUMPERZ.NET)を用いたCSRF対策について具体的に説明する。

この記述に続いて、Guardian@JUMPERZ.NETのCSRF防御戦略と設定方法が説明されている。それは、Webページにトークンを自動的に埋め込んで、フォームの受け取り側でチェックするというものだ。トークンをチェックするページは明示する必要があり、設定は少々面倒となる。このため、上記の分類では(c)となる。また、トークン利用の他、Refererをチェックする方式でも実装は可能だろうが、私はそのようなWAFを見たことはない*5

大河内氏はおそらく金床本を読んでおられないのだろう。日本でWAFビジネスをされるのであれば、金床本くらいは一度目を通しておかれることをお勧めしたい。

アクセス制御不備に対する防御

アクセス制御(認可)の問題については、大河内氏は以下のように記述しておられる。

アクセス制限の不備もWAFには判別不可能です。たとえば管理者ページを認証機構なし設置し、単にそのほかのページからリンクしていないだけ、というケースを考えてみましょう。この場合、URLを知っている者のみがアクセス可能ですが、それが容易に思いつくものか思いつかないものか、いずれであってもWAFには通常のWebページと区別できないため防御できません。

「現状の課題と“完璧なWAF”」より引用

この内容について検討してみよう。

アクセス制御(認可)の不備について、ウェブ健康診断仕様では以下の3種類の診断パターンを用意している。

  1. URL操作により、現在のユーザでは実行権限のない機能が実行可能
  2. 文書ID、注文番号、顧客番号等がパラメータにより指定されている場合、そのID 類を変更して、元々権限のない情報を閲覧できるか
  3. 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

f:id:ockeghem:20100505225854p:image:left

このように、WAFには典型的な認可不備に対する防御機構が用意されている。したがって、「WAFには通常のWebページと区別できないため防御できません」という指摘は誤りだ。

もっとも、認可処理はセキュリティ機能の根幹といえる部分であるため、アプリケーションの認可機能に欠陥を残したままWAFだけの防御で運用することは不安だという議論はあるだろう。また、認可不備は上記3パターンだけでなく色々なバリエーションがあるので、WAFで常に防御できるわけではない。しかし、それならそのように表現すれば良いだけの話で、WAFが原理的に認可不備を防御できないような表現は誤りだ。

チューニングについて

大河内氏の寄稿の後半は、“完璧なWAF”を実現するチューニングの話題に移るのだが、このチューニングの部分もかなりユニークだ。氏は、初期状態のWAFは非常に不完全な状態で、チューニングにより完全な状態にする必要があると指摘する。

WAFの初期状態(いわゆる最低限のブラックリストのみ)ではおおよそ50%程度の数値であると表現できます。チューニングをすることで60〜70%まで上げることができるでしょう。チューニングをきつくすると、120%となりサイトの機能が一部動作しなくなります。では、残りの30〜40%のみ上げるにはどうすればいいのでしょうか。

筆者は検知システムと同様、WAF+チューニング+サービスで100%に限りなく近づけることができると考えています(図3)。

f:id:ockeghem:20100505225853p:image:left

図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”を導入すれば解決するのだろうか

*2WAFでWebアプリの脆弱性を守れるか参照

*3:Citrixについて未調査

*4:厳密には、SQLインジェクション攻撃が成立するためには、unionの前にシングルクォートか式が必要だ

*5:手動でルールを追加する方法であれば、多くのWAFで対応可能であると思われる

*6デフォルトではいずれもオフになっていて、導入時に設定する必要がある

*7:False Negativeを調べる方法として、WAF越しに脆弱性診断をするという方法があるが、寄稿では触れられていない。このアプローチだと、網羅的に診断しないとFalse Negativeの洗い出しが出来ないので、コストはかなり高くなる。

cdcd 2010/05/25 20:58 一経営者としてあまりに観点の違いがあり指摘したい。結局のところ貴殿はどうしたらよいかの発言がないのはどうしてか?揚げ足だけとっているだけではないか。大河内氏は役職をみたところマネージャでありエンジニアではない。大きな視点での会社のサービスアピール寄稿だと考えるべきではないか。貴殿は育ち盛りの若いエンジニアだと推測されるが経営者とは思えない発言である。今後貴殿は出版元である技術評論社や大河内氏の所属する組織と仕事をすることはないのであろうが、あまりに幼稚すぎる。エンジニアな観点はよくわからないが、確実に誤りと判断されることがないのであれば(少なくとも常識人であれば)公の場での発言はないのではないか。前提条件が不明確なら個人的に問い合わせを行い、結果を載せるのであればまだ理解できるが貴殿の対応はこのような発言を私が行いたくなるほどいただけない。

ockeghemockeghem 2010/05/27 00:40 cdさん、コメントありがとうございます。私の文章を読んで不快の念を覚えられたようで、お詫び致します。
確かに大河内氏はエンジニアではないと理解していますが、そんなことは内容の不正確さに対する言い訳になるのでしょうか。セキュリティExpertは1580円もする専門書です。『大きな視点での会社のサービスアピール寄稿だと考えるべきではないか』ということですが、これは記事広告という意味でしょうか? 記事広告ならば、これは記事広告であるということがわかるように書くのが業界のルールだと思いますが、記事広告だとは読み取れませんでした。記事広告と分かるように書いてあれば、私も大人気ない書き方はしなかったと思います。
『今後貴殿は出版元である技術評論社や大河内氏の所属する組織と仕事をすることはないのであろうが、あまりに幼稚すぎる』というご指摘、『幼稚すぎる』というご批判に対してはまぁそうかなと思いますが、大河内氏の所属する組織とは過去に仕事をご一緒したことがあり、今後もその可能性はあります。そのような状況下で、私は実名を明らかにした上で記事の批判をしているのです。
『エンジニアな観点はよくわからないが、確実に誤りと判断されることがないのであれば』ということですが、私は確実な誤りについての指摘をしています。それがわかりにくかったということであれば、私の文章がへたくそだったのでしょうが、本名を明かしてブログを書き、批判相手の所属する組織に知り合いがいっぱいいる状態では、不確かなことは書けません。そういう状況下で、責任を負った上で書かざるを得ない状況だったわけです。あまりにも技術的に不正確な内容で、所属組織の名声を傷つけるような内容だったからです。
私も一経営者として、本名を公開してリスクをとった上でモノを書いています。大河内さんも実名と組織の看板を背負ってモノを書いています。ですから、対等な立場だと思っています。ですから、cdさんも経営者ということであれば、実名で議論をしませんか?

cdcd 2010/05/28 00:00 意図が伝わっていないのが貴殿の将来にとって残念だと思い、貴殿の為に今一度時間を割いてコメントをする。
貴殿は前提がわからないと言い訳をした上で指摘をしている。確実な誤りというのであれば前提が〜という言い訳は必要ないのではないか。前提が正しいとした推論上での確実な誤りは確実な誤りといえず、記事全体に誤った印象を与え誹謗中傷しているのではないか。前提が貴殿の考察と違っていれば、貴殿が誤った指摘をしても貴殿がせめられることはなく(前提が違ったと言い訳できる)、逆であった場合は貴殿は損はしないとなんともズルい書き方で発言をしている。どうして前提が不明であれば、なぜ確認した上で発言をしないのだろうか。なぜそんなズルい発言をするのであろうか。
仮に貴殿の発言が正しいと仮定して出版社からみて非公式の場で(この場で)貴殿が指摘をするよりも、貴殿が出版社や寄稿者に指摘し、出版社や寄稿者に対応をしていただいたほうが寄稿者や出版社、読者にたいしてよい結果となるとの考えにはならないのだろうか?こういったところを大人気ないと言っているのである。
広告記事について広告記事と書かない広告だから宣伝効果があると考えないのだろうか。専門家である貴殿が見ても判断つかない記事であるからよくできている記事なのではと思う。
貴殿が経営者と名乗るのであれば、寄稿者の立場を考慮して立場にあった発言をするべきである。寄稿内容についても出版社が求める事項と文字数の制限や宣伝などを考えると大河内氏は前提を削ったと考えに至らないのはなぜだろうか。
仕事についてだが、今後も一緒に仕事をする可能性があるといえる貴殿の性格が素晴らしいと思う。
貴殿は、大河内氏だけでなく大河内氏の所属する会社、編集をした出版社も批判していることをお気づきであろうか。大河内氏の組織を調べてみると歴史のある大きな会社だと判断できる。その大きな会社が会社名を公開して寄稿する時に会社組織がする校正、専門誌であれば編集者も専門家であるからその専門の編集者の校正を批判しているのである。
最も一番不快だったのは、貴殿はどうしたらよいかの発言をせず指摘だけしている点であると今一度いっておく。その行為が誹謗中傷目的であると感じられたから深く不快な思いをした。批判だけかいて何が起きるのかもう少し考えられてみてはいかがだろうか。

ockeghemockeghem 2010/05/28 10:31 cdさん、コメントありがとうございます。
『その行為が誹謗中傷目的であると感じられたから深く不快な思いをした』ということですが、私は根拠を明示して批判をしています。技術的に間違っているという批判です。技術誌に載った寄稿に対して、根拠を明示して批判することを「誹謗中傷」とは言わないと思います。
『貴殿は、大河内氏だけでなく大河内氏の所属する会社、編集をした出版社も批判していることをお気づきであろうか。大河内氏の組織を調べてみると歴史のある大きな会社だと判断できる。その大きな会社が会社名を公開して寄稿する時に会社組織がする校正、専門誌であれば編集者も専門家であるからその専門の編集者の校正を批判しているのである。』
これはその通りです。でも、社内ではしかるべき人がチェックしてないんじゃないですかね。大河内氏の所属企業のエンジニアを何人も知っていますが、その人たちは素晴らしい知見の持ち主です。その方々が査読したら、あんな寄稿は通らないと思いますよ。つまり、チェックされていないことに対する批判をしていることになりますね。
それに、私は根拠を明示して批判しているのですから、異論があれば、根拠を明示して反論すればいいだけのことです。今のところ、そのような反論はありませんし、「徳丸さんひどいじゃないですか」というメールなども頂戴していません。
私が一番大切なことは、元寄稿の読者や、これからWAFを導入しようとしている一番の方々に有益な知識を提供することだと思っています。正しい知識を普及させるためには、間違った情報は訂正していかなければならないのです。あの本が出る前に査読を依頼されたのであれば、非公開の形で訂正を依頼することができます。しかし、あの本を買った人は既にたくさんいるわけですから、その方たちに向けて、「あの内容は間違っている。本当はこうだ」という情報を提供していくことがこのエントリの狙いです。だから、公開でやらざるを得ないのです。

Mr.SmokeTooMuchMr.SmokeTooMuch 2010/10/04 16:54 素晴らしい内容読ませていただきました。記事の中で、CSRF対策ちして、RefererでチェックしているWAFは存在します。確か、S社のSaaS型WAFと思います。

ockeghemockeghem 2010/10/06 08:00 Mr.SmokeTooMuchさん、コメントありがとうございます。
私もその後、代理店の方から、Citrixの新しいバージョンでは、トークン埋め込み方式でCSRF対策ができるようになったと伺いました。CSRFは原理的に対策可能なので、対応する製品は出てくるでしようね。もちろん、元エントリの全体の趣旨には影響しません(WAFでCSRF対策できないという意見に対する反論なので)。
ありがとうございました。また、遊びに来てください。

pclpcl 2011/12/16 12:19 徳丸さんの指摘された内容についてはおおむね共感できますが、
「WAFの初期設定に対する考え方」については大河内さんが正しいと思います。

過剰検知の少ない WAF は確かに運用しやすいですが、反対に False Negative が
発生しやすくなります。

その False Negative を取り除くために慣らし運用(学習)して、さらにシグネチャを
チューニングすることで、各顧客の環境に適した 完全な WAF が仕上がるのではないでしょうか。

・・・といいましても、WAF 自体それほど完成された製品ではないので、
正解なんてないのかな?とも思います。

なんにせよ、もっと議論する場所がほしいですねえ。

 | 
Google