概要

本記事では脆弱性診断時に何故WAFを無効化したほうがいいかについて記載する。

なお、本記事内での脆弱性診断とは「Webアプリケーション内にXSSやSQLインジェクション等のセキュリティホールが存在しないかを調査するサービス(ブラックボックステスト)」を指し、WAFとはWebアプリケーションの脆弱性を悪用した攻撃から保護するファイアウォールを指す。

脆弱性診断を依頼される際、少なくない場面でWAFを有効化したままの状態で検査を依頼されることがある。

依頼者曰く「実際の運用では常にWAFを有効化しているのだから、この状態でどのようなセキュリティホールが存在するか確認してほしい」とのこと。

理屈はわかるが、それでは脆弱性診断サービスを効果的に利用できないと考える。

本記事ではこの理由について記載する。

WAFの効果

まず、WAFとは実際にどのようなことを行うかを説明する。

簡単にいえば、脆弱性を利用した攻撃(リクエスト)が届いた際に、それらをブロックする。また、設定によっては攻撃したIPからのアクセスを遮断する。

どのようなものを攻撃と判断するか、それに対してどのような施策を行うかはWAFごとに異なるが、おおむね攻撃を遮断する機能だと思ってもらえればいい。

つまり、脆弱性診断のほとんどの調査はWAFに弾かれてしまう。

脆弱性診断の調査事項

次に、脆弱性診断とは何を調査しているのかを確認しよう。

以下のチェックリストが最も基本的なものになる。

https://www.ipa.go.jp/files/000017319.pdf

IPAが公開している「ウェブ健康診断仕様」であり、脆弱性診断のチェックリストが載っている。

この仕様書のXSSの項目(P10)から考えてみよう。

XSSのテストであれば、これらのパターンを実際にWebアプリケーションに送信し、その反応を見ることでXSSの有無を調査する。

上記の場合4項目だが、実際に脆弱性診断を行う各社は様々な脆弱性ごとに様々な検出パターンを用意し、テストに活用している。

そして、このテストパターンがどの様に選ばれるかというと「効率的に脆弱性を調査できるように」選ぶのである。効率的というのは可能な限り少ないパターンという意味だ。

重要なのは、脆弱性診断で使われる検査パターンは調査することに重点をおいており、決してWAFを通り抜けるためではない....という点である。

この調査と攻撃（サーバに攻撃を気づかれないように機密情報を抜き出す）は似て非なるものである。

検査パターンをWAFが防ぐ

WAFが有効された状態での脆弱性診断は非効率なものとなる。何故なら検出パターンの大部分がブロックされるからだ。

例えばWAFは「alert」という文字列が含まれたリクエストをブロックするとする（実際に多い）。すると先ほどのXSSの4項目のうち3項目がブロックされることになる。4項目である程度の網羅性を保っていた検査パターンが3項目がブロックされるのだから、テストとしては破たんしているといっていい。

ここで多くの人は「WAFがブロックするのだから、実際安全なのでは？」と思うだろう。それは間違っている。

先ほど述べたように、調査と攻撃は全く別物なのだ。

今回、検査パターンの多くに「alert」が含まれているが、これは攻撃として有効だからではなく、テスト結果としてわかりやすいからalert()を使っているのである。実際、攻撃者は悪意のあるスクリプトとしてalert()などは使わない。つまり、「alert」という文字列だけ防いでいても、実際の攻撃は何も防げてないのである。

もちろん、WAFはalert以外にも様々なパターンをブロックするが、それらはすべてのXSSの攻撃パターンを防いでくれると保証しているのだろうか？

あらゆる攻撃パターンを防いでくれるWAFなど、少なくとも私は知らない。

脆弱性診断はWAFの性能テストではない

脆弱性診断はWebアプリケーションの脆弱性対策を見るサービスである。

例えばXSSであれば「画面上で正しく文字をエスケープしているか」について確認する。

「あらゆるXSSの攻撃パターンを試すテスト」ではないのだ。

つまり、有効化されているWAFが、どのような攻撃をブロックし、どのような攻撃を通すか....という点については脆弱性診断は責任を持てない。これらを網羅的にテストすることは、ブラックボックステストである脆弱性診断には不可能だからだ。

WAFの性能については、WAFを提供しているベンダーに確認してもらうしかない。つまり脆弱性診断はWAFの性能テストではないのだ。

WAF環境下での脆弱性診断

診断するものがWAFが有効だと気付いた際に、各社によって異なるが２通りの行動パターンがあると思っている。

1. 可能な限りWAFをすり抜ける有効なテストをする

2. 通常通りのテストをする

どちらを選ばれるかはわからないが、どちらを選ばれても仕方ない。

特に自動検査ツールのみを使っているところは２を選ぶしかないだろう。

２を選んだ場合、ほとんどのテストは無意味なものとなる。先ほどのIPAのチェックリストに載っているような代表的な検査パターンはほぼ確実にWAFにブロックされるからだ。

重要なのは無意味という点であり、ブロックされることは安全の証明ではないということだ。XSSに例えるなら、alertという文字をブロックしても、実際にはその先の出力はエスケープする処理を実装してない可能性がある。

WAFにブロックされた場合、脆弱性診断としては「いいとも悪いともいえない」が結論になる。

1を選ぶ企業もあると思うが、先ほども言ったようにブラックボックステストにおいて、そのWAFに最も効果的な検査パターンを常に選べるわけではない。調査期間も長期化し、WAFがない場合に比べてどうしても診断精度は落ちる。

脆弱性診断元IPだけはWAFを無効化する

ここまで説明してきたように、脆弱性診断とWAFは極めて相性が悪い。

脆弱性診断はWebアプリケーションの脆弱性対策をみたいのに、WAFはその検査パターンをブロックし、結果として脆弱性対策が調べられない。

Webアプリケーションで根本的な脆弱性対策が取られていれば、様々な攻撃が行われても攻撃は成立しない。その調査をしているのに、別のセキュリティ機構に邪魔をされるのは、何のために調査を依頼されているのかわからなくなる。

もし、貴社が脆弱性診断をベンダーに依頼する場合は、診断元IPからのリクエストはWAFを通り抜けるようにしてほしい。多少手間かもしれないが、脆弱性診断にかかる費用を丸々無駄にするよりはマシなはずだ。

「実際の運用では常にWAFを有効化しているから」というのもわかるが、脆弱性診断で(WAFにより)問題なしと報告されても、実際に攻撃が成功してしまえば本末転倒である。

セキュリティ対策はテストを通るためではなく、攻撃を防ぐために行われるべきだ。