WAF導入の手引き

●WAFってなに？

特集特集

2008年7月9日（水） 17時15分

●WAFってなに？

WAFとは、Web Application Firewallの略称である。

Webアプリの普及と高機能化に伴って、それらをターゲットとする攻撃は年々増加の傾向にあるが、従来型のネットワークファイアウォールでは、サービスを行っていないポートへの外部からの接続をブロックするといった、低いレベルでの対策しか行えない。

Webアプリの脆弱性を狙った攻撃を正確に検知し防御するためには、アプリケーション層における通信内容を理解し、その妥当性を判断できる仕組みが必要なのである。

また、クレジットカード情報取り扱いのセキュリティ標準であるPCIDSSの要件6.6にも、WAFの設置もしくはアプリケーションのコードレビューの実施が明記されており、2008年7月から必須要件となるため、今後のWebアプリのセキュリティを語る上で欠かせない存在になりつつある。

●最近の攻撃傾向

読者諸氏の記憶に新しいところでは、SQLインジェクション・ワームによる広範な攻撃が行われ、多数のサイトでの被害が報告されているが、こうした攻撃に対抗するための手段としては、WAFが有効といえる。

また、これまでWebアプリに対する攻撃といえば、ECサイトに代表されるような、クレジットカード番号などの価値の高い情報を抱えるシステムがそのターゲットとなるケースが多かったが、昨今はこれにとどまらず、直接エンドユーザのPC内の情報を奪取しようとする傾向も多くみられる。

この攻撃の一般的な手法は、まずWebサイトのコンテンツを何らかの方法で改竄し、これを閲覧したPCに、各種不正プログラムをダウンロードさせるように仕向けるといったものである。

これが何を意味するかというと、重要情報を取り扱わないサイトであっても、そのサイトに脆弱性があれば、クライアント攻撃の踏み台にされる可能性が十分にあるということである。踏み台にされたサイトは、期せずして加害者サイドにまわり、犯罪者の攻撃に加担することとなる。

●IDS/IPSではだめなのか

実は前述のSQLインジェクション攻撃は、WAFでなくとも、IDS/IPSを用いることで対策可能である。

ブラウザとWebサーバの間にはさまざまなデータ（文字列と言ってしまってもよいだろう）が流れているが、SQLインジェクション検出の一般的な手法は、単純にその文字列の中から、危険とされる文字列パターンを見つけ出すことによって行われる。

このような単純な文字列比較であれば、そのデータがアプリケーションにとってどのような意味を持つかということは考慮しなくても目的は達せられる。

こうした検出方式はネガティブセキュリティ方式とよばれ、IDS/IPSで一般的に採用されている。アンチウイルスソフトにおけるパターンファイルによる検出と同じようなものと考えていただければよい。WAFにおいては、不正アクセスのパターンを「ブラックリスト」化し、一致する通信を検知・遮断するという働きである。

しかし、Webアプリに対する様々な攻撃は、こうしたシンプルな文字列探査だけでは対応できない。

たとえばパラメータ改竄を例にとってみよう。あるWebアプリの画面に下記のようなリンクがあったとする。

https://site/members.php?uid=abc12345

そこで、そのリクエスト内のuidパラメータを

https://site/members.php?uid=cde45678

のように書き換えて送信したとする。この行為を検出するには、まず第一に、リクエスト文字列を分解して、uidというパラメータを認識できなければいけない。

さらに、最初のリンクを含むページを表示したブラウザと、次に変更したパラメータを送信したブラウザが同一インスタンスであることを認識できなければいけない。

しかも、パラメータは上のようなリンク埋め込み型だけではない。エンドユーザがformから入力して送信するような場合にはパラメータの書き換えは、全く正しい動作となる。

このように、アプリの正しい動きを「ホワイトリスト」として定義して、そこから逸脱する通信を検知・遮断する働きを、ポジティブセキュリティ方式と呼ぶ。

また、WAF独特の機能として、出力内容のクローキングと呼ばれるものがある。

これはWebサーバからブラウザに出力されるHTMLの中身を解析し、クレジット番号や個人情報にあたる情報が含まれていた場合、これをマスキング、あるいは除去してしまう機能である。

WAFの一枚上手をいくような攻撃者によって、仮にSQLインジェクション攻撃が成功し、クレジットカード番号の一覧が奪取されてしまうような局面においても、最後の出力段階で情報流出を阻止することができる。

とはいえ、誤解しないでいただきたいのは、IDS/IPSはWebアプリに特化しない、もっと広い範囲での不正アクセスを検知するものであり、短絡的にWAFより劣ると判断するのは誤りである。要は「何をどういった攻撃から守るべきか」という、基本的なセキュリティ設計に基づき、どのような手段を講じるかを適切に判断することが重要なのである。

●代表的な製品と製品選びのポイント

WAFの導入形態は大きくは、アプライアンス型、別製品の追加モジュールとして導入できるもの、ソフトウェアとして提供されるもの、の3種類ほどに分けられる。それぞれパフォーマンスやコスト面で一長一短があるといえる。また、各製品とも、ネガティブ及びポジティブセキュリティの検知機能を実装しており、特にネガティブ方式については、製品によって大きな違いはないと考えてよいだろう。主要アンチウイルスソフトのパターンファイルがメーカ毎に大きな違いがないのと同様だ。

・iMPERVA SecureSphere WAF（アプライアンス製品）

IPを持たない透過型ブリッジとして構成可能であり、既存環境に与える影響を最小に抑えられる。DMG/DSGと組み合わせることで、Web+DBシステムに対する包括的なセキュリティ対策をワンボックスで実現可能。

・Barracuda Web Application Controller（アプライアンス製品）

ロードバランサー、キャッシュサーバ、SSLアクセラレータ機能およびコンテンツ圧縮機能を統合。クレジットカード番号の漏洩防止機能や、サーバの種類・バージョン情報等を隠蔽するクローキング機能を実装。

・F5ネットワークス　BIG-IP Application Security Manager（モジュール/アプライアンス製品）

クレジットカード番号、電話番号、サーバのバージョンなどの情報をマスキングするなどしてユーザから見えないようにする。アプライアンス単体での提供とともに、ロードバランサーBIG-IPのモジュールとしての導入も可能。

・F-Secure SiteGuard（ソフトウェア製品）

株式会社ラックが提供するカスタム定義ファイルを用いて最新攻撃パターンにも対応。Webサーバそのものへの導入も可能。リバースプロキシーや、透過型モードなど、多様な導入構成に対応。

いずれの製品にしても、カスタムWebアプリの脆弱性を正しく認識して、適切な設定を施すことで、格段に防御効果の向上が見込める。そのためには、アプリ診断などと組み合わせたポリシーチューニングを行えるようなきめ細かいサポート体制が必要であり、導入に携わるSIerの選択が非常に重要なポイントになってくる点はぜひ意識していただきたい。

【執筆：NTTデータ・セキュリティソリューション本部ソリューション部インターネットソリューションG 天野寛生】

NTTデータ・セキュリティ
http://www.nttdata-sec.co.jp/
PCIDSS要件6.6、コードレビューとWAF導入選択の留意事項
https://www.netsecurity.ne.jp/3_11862.html

PCIDSS対策研究所
https://www.netsecurity.ne.jp/pcidss/

《ScanNetSecurity》