危険なWeb攻撃から身を守る「Webアプリケーションファイアウォール（WAF）」の全て という記事を見つけました
今更聞けない、「WAF」とは何か
今やインターネットを介したサイバー攻撃の大半がWebを標的にしている。このことから、WebサイトやWebアプリケーションの保護に特化したセキュリティ製品であるWAFに対する認知度が急速に高まっている。
認知度は向上しているものの、従来型のネットワークセキュリティ製品と比較して、具体的に機能レベルでどのような差異があるのかについては、意外と知られていない。また一部同様の機能を持つ「次世代型ファイアウォール」と混同されるケースも多いのが現状だ。WAFとは何かについて、ここで整理しておこう。
WAFに求められる機能
機能面で見ると、WAFに分類される製品は、以下のような機能を特に備えるものとして捉えることができる。
HTTP解析機能
WAFの中心的な機能がHTTP解析機能だ。この機能を理解するために、HTTPによる通信の仕組みを簡単に説明していこう。
Webアプリケーションと、Webブラウザなどのクライアントとの通信は、一対のクライアントからの通信要求である「リクエスト」と、Webアプリケーションからの応答である「レスポンス」が多数発生することで成り立っている。
インターネットのプロトコル仕様を記載したRFCでは、クライアントからのリクエストは「URL」と「送信データ（パラメータ）」を含み、「GET」「POST」などのコマンドを使うといった、データの送信手順が定められている。Webアプリケーションやクライアントは、RFCが定めるこうした手順に従って、データを送受信している。
データの送受信時には、ヘッダ情報も合わせて送信される。特に重要なヘッダ情報として、要求の転送元を示す「referrer」、サーバ側から割り当てられた情報を保持する「cookie」などがある。
サーバからの応答レスポンスに必ず含まれるのが「レスポンスコード」だ。レスポンスコードは、リクエスト要求が成功したかどうか、また失敗した理由などを判断する材料を提供する。
膨大なトラフィックの中から、リクエストやレスポンスを識別して論理的に理解する――。これがWAFの最も基本的な処理内容である。
SSL復号機能
Webでは、重要な情報を含むデータの送受信にはSSL暗号化を利用することが一般的であり、トラフィックをそのまま解析しても、送受信データの中身を識別できない。
WAFの配置方法に目を向けると、
•WAFをL2ブリッジとして動作させ、既存環境に透過的に設置する「透過モード」
•外部からのTCPセッションを一度WAFで終端し、別セッションでWebサーバと通信する「リバースプロキシモード」
•L2／L3スイッチのモニターポート（監視用ポート）に接続する「スニフィングモード」
など複数ある。どの配置方法を取るにしても、性能を落とさずにSSL通信の復号や解析ができることが必須要件である。
ユーザーセッション追跡機能
HTTPでは、上述したcookieという識別子をリクエストに付与することで、個別のユーザーセッションの状態を保持できる。最近は、こうしたセッション管理の仕組みを悪用する「クロスサイトリクエストフォージェリ（CSRF）」「セッションフィクセーション」といった攻撃が盛んだ。こうした中、WAFにはHTTPのユーザーセッションを追跡する機能が求められている。
ブラックリスト検知、シグネチャ更新機能
連載第2回「“危ないWebアプリ”を生む『既存コードの脆弱性』の怖さ」で紹介した、CMSの既知の脆弱性を狙った攻撃を防御するには、シグネチャを利用した「ブラックリスト検知」が非常に有効だ。脆弱性は日々新しいものが報告されるので、シグネチャの更新頻度は高い方が望ましい。
学習によるホワイトリスト機能
Webアプリケーションの構造はWebサイトによって異なる。そのため、画一的な防御の仕組みでは攻撃に対処できない場合も多い。そのため、各Webアプリケーションが日常的に利用するURLやパラメータを学習し、通常のWebアプリケーション利用から逸脱した疑わしいアクセスを遮断できるホワイトリスト機能が重要になる。
相関分析機能
Web攻撃はますます巧妙化しており、セキュリティ対策製品による検知を回避する手法も確立している。上述したブラックリスト検知などの単一の検知手段だけで判断するのではなく、複数の検知手段で得た検知結果の相関をとり、総合的に危険度を判断する仕組みが重要だ。
カスタムポリシー作成機能
連載第4回「“パスワード使い回し”を悲劇に変える『アカウントリスト型攻撃』とは」で紹介したように、アカウントリスト型攻撃などをブロックする手段として有効なのが、カスタムポリシーの作成機能だ。時間によって制御のしきい値を変えたり、発信元のアドレスやURL／パラメータなどの制御条件を柔軟に変更できることが望ましい。
レピュテーション機能
IPアドレスや地理情報といったリクエストの発信元情報は、攻撃を判断する際の重要な情報となる。ただし、匿名プロキシや踏み台となるボットサーバなどを経由して発信元を隠蔽し、攻撃源の特定を難しくすることは多くの攻撃で見られる。こうした手法に対抗する万能な手法はないが、過去の実績や第三者情報を利用したレピュテーションによって判断する方法が有効だ。
上述した全ての機能は、本連載で特に紹介してきた最新の脅威の防御において重要な役割を果たす。他のゲートウェイ／ネットワークセキュリティ製品と比較しても、アプリケーション層の防御においてWAFは全般的な強みを発揮し、かつ柔軟なカスタマイズも可能なのが強みだ。特に、HTTP解析機能やユーザーセッション追跡機能は、アプリケーション層の防御に焦点を当てたWAFならではの機能だといえる。
WAFの選定ポイント
セキュリティ製品を比較する際に広く用いられているのが、脆弱性攻撃の「検知率」や脆弱性の「カバー率」といった指標である。既存の脆弱性にどの程度対処できるか、公開された脆弱性への対応スピードが速いかどうかなどを測るために利用する。
こうした指標を基にした比較は、WAF製品の選定に当たっては必ずしも適切ではない。高い検知率は、逆に高い誤検知率にもつながり、正常な通信を止めてしまう可能性があるからだ。Webアプリケーションの攻撃手法は比較的高度で複雑であり、1つの脆弱性を狙う攻撃手法が多数存在する場合もあることが背景にある。
WAFの検知率や誤検知率を評価するためには、Webサーバに対して診断ツールを仕掛けるだけでは難しく、検知率などのカタログ値に惑わされないようにしたい。できる限り公平にWAFの能力を評価する方法として、以下が挙げられる。
実環境における検証
自社のWebサイトのトラフィックを検査できる箇所にWAFを試験導入し、一定期間の動作確認をすることで、攻撃検知能力や正常トラフィックの処理を確認できる。実環境に導入する場合には、上述したスニフィングモードで導入ができるWAF製品があれば、運用中のWebサイトに影響を与えずにテストできる。
業界団体作成のWAF評価基準書
Webアプリケーションセキュリティに関する業界団体「Web Application Security Consortium（WASC）」が複数のWAFベンダーの意見を集約し、WAFの評価基準書「Web Application Firewall Evaluation Criteria（WAFEC）」を作成している。WAFに求められるさまざまな要件が網羅されているので、製品を比較する際の参考になるだろう。
WAF専用の評価ツール
Impervaの「WAF Testing Framework」など、高度なアプリケーション攻撃からWebサイトが守られていることを検証するための評価ツールも登場し始めている。こうした専用ツールの特徴は、誤検知および検知漏れの双方の指標でWAFを評価可能なことだ。攻撃を防御できるかどうかという視点だけではなく、攻撃と誤認しやすい正常なトラフィックもシミュレーションできるからである。
WAFの提供パターンはさまざま
現在、さまざまなタイプのWAF製品／サービスが存在する。提供形態で分類すると、（A）専用アプライアンスをネットワークに設置する「オンプレミス型」、（B）WebサービスとしてWAFを提供する「クラウド型」に大きく分類できる。それぞれの特徴を以下にまとめた。
高度な利用方法として、オンプレミス型とクラウド型双方のいいとこ取りをした「ハイブリッド型」で利用するケースもある。大量のネットワーク／サーバリソースを占有するDDoS攻撃の対策を例に取ってみよう。トラフィック全体をクラウド型のWAFでいったんフィルタリングすることで、DDoS攻撃のトラフィックを自社サイトの外部で止めることが可能となる。その上で、オンプレミス型のWAFは、より綿密にカスタマイズしたポリシーで運用し、多層的な防御を実施できる。
6回の連載を通して、Webアプリケーションに関する脅威のトレンドや対策法を紹介してきた。Webアプリケーションは今後もますます発展していくだろう。利便性と安全性は常にトレードオフの関係にある。「ユーザーにとっていかに便利なシステムを作るか」という議論はもちろん重要だが、セキュリティについても同じぐらいの時間を費やして議論しなければならない。本連載が、今後のWebアプリケーションセキュリティ対策を検討する一助となれば幸いである。
果たして公平な評価ツールはあるのだろうか 未知のウイルスが相手なのだから
今更聞けない、「WAF」とは何か
今やインターネットを介したサイバー攻撃の大半がWebを標的にしている。このことから、WebサイトやWebアプリケーションの保護に特化したセキュリティ製品であるWAFに対する認知度が急速に高まっている。
認知度は向上しているものの、従来型のネットワークセキュリティ製品と比較して、具体的に機能レベルでどのような差異があるのかについては、意外と知られていない。また一部同様の機能を持つ「次世代型ファイアウォール」と混同されるケースも多いのが現状だ。WAFとは何かについて、ここで整理しておこう。
WAFに求められる機能
機能面で見ると、WAFに分類される製品は、以下のような機能を特に備えるものとして捉えることができる。
HTTP解析機能
WAFの中心的な機能がHTTP解析機能だ。この機能を理解するために、HTTPによる通信の仕組みを簡単に説明していこう。
Webアプリケーションと、Webブラウザなどのクライアントとの通信は、一対のクライアントからの通信要求である「リクエスト」と、Webアプリケーションからの応答である「レスポンス」が多数発生することで成り立っている。
インターネットのプロトコル仕様を記載したRFCでは、クライアントからのリクエストは「URL」と「送信データ（パラメータ）」を含み、「GET」「POST」などのコマンドを使うといった、データの送信手順が定められている。Webアプリケーションやクライアントは、RFCが定めるこうした手順に従って、データを送受信している。
データの送受信時には、ヘッダ情報も合わせて送信される。特に重要なヘッダ情報として、要求の転送元を示す「referrer」、サーバ側から割り当てられた情報を保持する「cookie」などがある。
サーバからの応答レスポンスに必ず含まれるのが「レスポンスコード」だ。レスポンスコードは、リクエスト要求が成功したかどうか、また失敗した理由などを判断する材料を提供する。
膨大なトラフィックの中から、リクエストやレスポンスを識別して論理的に理解する――。これがWAFの最も基本的な処理内容である。
SSL復号機能
Webでは、重要な情報を含むデータの送受信にはSSL暗号化を利用することが一般的であり、トラフィックをそのまま解析しても、送受信データの中身を識別できない。
WAFの配置方法に目を向けると、
•WAFをL2ブリッジとして動作させ、既存環境に透過的に設置する「透過モード」
•外部からのTCPセッションを一度WAFで終端し、別セッションでWebサーバと通信する「リバースプロキシモード」
•L2／L3スイッチのモニターポート（監視用ポート）に接続する「スニフィングモード」
など複数ある。どの配置方法を取るにしても、性能を落とさずにSSL通信の復号や解析ができることが必須要件である。
ユーザーセッション追跡機能
HTTPでは、上述したcookieという識別子をリクエストに付与することで、個別のユーザーセッションの状態を保持できる。最近は、こうしたセッション管理の仕組みを悪用する「クロスサイトリクエストフォージェリ（CSRF）」「セッションフィクセーション」といった攻撃が盛んだ。こうした中、WAFにはHTTPのユーザーセッションを追跡する機能が求められている。
ブラックリスト検知、シグネチャ更新機能
連載第2回「“危ないWebアプリ”を生む『既存コードの脆弱性』の怖さ」で紹介した、CMSの既知の脆弱性を狙った攻撃を防御するには、シグネチャを利用した「ブラックリスト検知」が非常に有効だ。脆弱性は日々新しいものが報告されるので、シグネチャの更新頻度は高い方が望ましい。
学習によるホワイトリスト機能
Webアプリケーションの構造はWebサイトによって異なる。そのため、画一的な防御の仕組みでは攻撃に対処できない場合も多い。そのため、各Webアプリケーションが日常的に利用するURLやパラメータを学習し、通常のWebアプリケーション利用から逸脱した疑わしいアクセスを遮断できるホワイトリスト機能が重要になる。
相関分析機能
Web攻撃はますます巧妙化しており、セキュリティ対策製品による検知を回避する手法も確立している。上述したブラックリスト検知などの単一の検知手段だけで判断するのではなく、複数の検知手段で得た検知結果の相関をとり、総合的に危険度を判断する仕組みが重要だ。
カスタムポリシー作成機能
連載第4回「“パスワード使い回し”を悲劇に変える『アカウントリスト型攻撃』とは」で紹介したように、アカウントリスト型攻撃などをブロックする手段として有効なのが、カスタムポリシーの作成機能だ。時間によって制御のしきい値を変えたり、発信元のアドレスやURL／パラメータなどの制御条件を柔軟に変更できることが望ましい。
レピュテーション機能
IPアドレスや地理情報といったリクエストの発信元情報は、攻撃を判断する際の重要な情報となる。ただし、匿名プロキシや踏み台となるボットサーバなどを経由して発信元を隠蔽し、攻撃源の特定を難しくすることは多くの攻撃で見られる。こうした手法に対抗する万能な手法はないが、過去の実績や第三者情報を利用したレピュテーションによって判断する方法が有効だ。
上述した全ての機能は、本連載で特に紹介してきた最新の脅威の防御において重要な役割を果たす。他のゲートウェイ／ネットワークセキュリティ製品と比較しても、アプリケーション層の防御においてWAFは全般的な強みを発揮し、かつ柔軟なカスタマイズも可能なのが強みだ。特に、HTTP解析機能やユーザーセッション追跡機能は、アプリケーション層の防御に焦点を当てたWAFならではの機能だといえる。
WAFの選定ポイント
セキュリティ製品を比較する際に広く用いられているのが、脆弱性攻撃の「検知率」や脆弱性の「カバー率」といった指標である。既存の脆弱性にどの程度対処できるか、公開された脆弱性への対応スピードが速いかどうかなどを測るために利用する。
こうした指標を基にした比較は、WAF製品の選定に当たっては必ずしも適切ではない。高い検知率は、逆に高い誤検知率にもつながり、正常な通信を止めてしまう可能性があるからだ。Webアプリケーションの攻撃手法は比較的高度で複雑であり、1つの脆弱性を狙う攻撃手法が多数存在する場合もあることが背景にある。
WAFの検知率や誤検知率を評価するためには、Webサーバに対して診断ツールを仕掛けるだけでは難しく、検知率などのカタログ値に惑わされないようにしたい。できる限り公平にWAFの能力を評価する方法として、以下が挙げられる。
実環境における検証
自社のWebサイトのトラフィックを検査できる箇所にWAFを試験導入し、一定期間の動作確認をすることで、攻撃検知能力や正常トラフィックの処理を確認できる。実環境に導入する場合には、上述したスニフィングモードで導入ができるWAF製品があれば、運用中のWebサイトに影響を与えずにテストできる。
業界団体作成のWAF評価基準書
Webアプリケーションセキュリティに関する業界団体「Web Application Security Consortium（WASC）」が複数のWAFベンダーの意見を集約し、WAFの評価基準書「Web Application Firewall Evaluation Criteria（WAFEC）」を作成している。WAFに求められるさまざまな要件が網羅されているので、製品を比較する際の参考になるだろう。
WAF専用の評価ツール
Impervaの「WAF Testing Framework」など、高度なアプリケーション攻撃からWebサイトが守られていることを検証するための評価ツールも登場し始めている。こうした専用ツールの特徴は、誤検知および検知漏れの双方の指標でWAFを評価可能なことだ。攻撃を防御できるかどうかという視点だけではなく、攻撃と誤認しやすい正常なトラフィックもシミュレーションできるからである。
WAFの提供パターンはさまざま
現在、さまざまなタイプのWAF製品／サービスが存在する。提供形態で分類すると、（A）専用アプライアンスをネットワークに設置する「オンプレミス型」、（B）WebサービスとしてWAFを提供する「クラウド型」に大きく分類できる。それぞれの特徴を以下にまとめた。
高度な利用方法として、オンプレミス型とクラウド型双方のいいとこ取りをした「ハイブリッド型」で利用するケースもある。大量のネットワーク／サーバリソースを占有するDDoS攻撃の対策を例に取ってみよう。トラフィック全体をクラウド型のWAFでいったんフィルタリングすることで、DDoS攻撃のトラフィックを自社サイトの外部で止めることが可能となる。その上で、オンプレミス型のWAFは、より綿密にカスタマイズしたポリシーで運用し、多層的な防御を実施できる。
6回の連載を通して、Webアプリケーションに関する脅威のトレンドや対策法を紹介してきた。Webアプリケーションは今後もますます発展していくだろう。利便性と安全性は常にトレードオフの関係にある。「ユーザーにとっていかに便利なシステムを作るか」という議論はもちろん重要だが、セキュリティについても同じぐらいの時間を費やして議論しなければならない。本連載が、今後のWebアプリケーションセキュリティ対策を検討する一助となれば幸いである。
果たして公平な評価ツールはあるのだろうか 未知のウイルスが相手なのだから