日常的に繰り返されているWebアプリケーションへの攻撃

Webアプリケーションの脆弱性を利用して行われる個人情報の窃取（せっしゅ）やコンテンツの改ざんといった攻撃は、もはや珍しいことではありません。昨年、日本の大手エレクトロニクスメーカーが提供するWebサービスに対して攻撃がしかけられ、1億人強のユーザの個人情報が流出し、大きな騒ぎとなったのは記憶に新しいところです。この状況は今年になっても改善されておらず、毎月のように情報漏えいのニュースが聞こえてきます。

こうしたWebアプリケーションへの攻撃には、さまざまな手法が使われています。代表的な攻撃手法として「SQLインジェクション」があります。これはフォームにSQL文を直接入力し、開発者が意図していない動作をWebアプリケーションに行わせるというもの。これにより、ユーザ認証をすり抜けたり、権限がなくてもデータベース内の全データを窃取することが可能になります。

ほかにも、Webアプリケーションの脆弱性を突いて攻撃する手法は数多く存在します。ユーザを特定するためのセッションIDを悪用する「クロスサイトスクリプティング」や、ユーザに意図しない書き込みや変更をさせる「クロスサイトリクエストフォージェリ⁠」⁠、WebサーバのOS上でコマンドを実行する「OSコマンドインジェクション」などが有名です。Webアプリケーション開発の際は、こうした攻撃手法について意識し、脆弱性を作り込まないようにする必要があります。

それでは、Webアプリケーションはどの程度安全に構築されているのでしょうか。「⁠ウェブアプリケーション診断の結果（2010⁠）⁠」⁠（⁠図1）によると、実に98％のWebサイトが何らかの脆弱性を抱えており、さらに、危険度の特に高い脆弱性が存在するWebサイトは全体の2／3以上だと指摘しています。これらのWebサイトは自ら費用を支払って脆弱性診断を行ったもので、検査を行っていないWebサイトで脆弱性が作り込まれている可能性はもっと高くなると推測されます。つまり、多くのWebサイトで何らかの脆弱性が残されている可能性があるわけです。

また、WAF（Web Application Firewall）を導入しているWebアプリケーションに対して昨年1年間でどの程度の攻撃があったのかを調査したところ、45万回以上の攻撃が行われていたことがわかりました（図2、※1⁠）⁠。最も攻撃回数が多かったのはSQLインジェクションで、次いで不正なコンテンツのスキャン、コマンドインジェクション、パスワードが保存されている「/etc/passwd」への攻撃、開発者が意図していないパスを参照する「パスの乗り換え」（⁠パストラバーサル）などが続いています。

Webアプリケーションの脆弱性を解消できない理由

こうした攻撃に対処するには、Webアプリケーションの設計／実装／テストの各フェーズにおいてセキュリティを考慮する必要があります。ただ、短納期、低予算で進められることが多いWebアプリケーション開発の現状を考えると、十分にセキュリティに配慮して開発することは現実的に難しいケースが大半でしょう。具体的な対応の1つとして、テストフェーズで行う脆弱性診断が挙げられますが、それも相応のコストと期間が必要であり、納期や予算の問題から見送られる場合が少なくありません。

しかしながらWebアプリケーションが攻撃された場合、極めて甚大な被害を受ける恐れがあります。たとえば個人情報が漏えいすれば、サービスを提供する企業の信用失墜につながるほか、情報が漏えいした個人への賠償問題やサービス再開までの売り上げ停止も発生します。受託開発企業にとっては、発注側の企業から損害賠償を求められることもあるでしょう。

また、脆弱性が発覚したあとの改修に長い時間がかかることも問題の1つです。独立行政法人情報処理推進機構の調査によれば、脆弱性が判明したWebアプリケーションの半数以上で、その改修に1ヵ月以上かかったとしています。すでにサービスを提供している場合、脆弱性を放置したままの運用はリスクが高いことを考えると、サービスの停止、あるいは当該機能の削除といった対応をせざるを得ません。改修に時間がかかれば、それだけ収益に大きな影響の出る恐れがあるわけです。

ファイアウォールやIPSでは防げない攻撃を遮断するWAF

こうしたWebアプリケーションの脆弱性に対する解決策として活用したいのがWAFです。Webサーバの前面に配置することでWebアプリケーションに対する入力内容をチェックし、攻撃と判断される内容が含まれていれば通信を遮断、あるいはログとして記録するセキュリティソリューションです。これにより、Webアプリケーションに脆弱性が残っていたとしても、情報漏えいなどの被害を避けられます。Webサーバを構成するOSやミドルウェア、その他のWebサービスで新たな脆弱性が発見されている現状を考慮すると、Webサイトの脆弱性対策はサービス提供の時点で終わるものではなく、常に対策を行う必要があります。そのため、新たに発見された脆弱性にもシグネチャの追加で対応できるWAFへの期待は高いものがあります。

WAFは、通常通信ポートを開放しているHTTPやHTTPSへの入力内容によって行う防御に特化しているため、ファイアウォールやIDS（Intrusion Detection System⁠）⁠／IPS（Intrusion Prevention System）といったポートごとの通信を防御するセキュリティ装置では検知が難しい攻撃でも対策が可能です。

手軽に無償で試せるベリサインのクラウド型WAF

こうしたWAFの1つとして、ベリサインから提供されているのが「クラウド型WAF」です。名前のとおりクラウドサービスとして提供されているため、指定のOS環境に（必要に応じてパッチをあてて）ソフトウェアをインストールしたり、ネットワーク構成を変更してアプライアンスを設置したりする必要はありません。導入時に必要な作業はDNSの設定変更だけで、Webアプリケーションで使っているドメイン名をクラウド型WAFのアドレスに紐付ければ完了です。これで、クライアントとの通信は必ずWAFを経由することになり、攻撃を意図した通信は自動的に遮断されます（図3⁠）⁠。

なお、ベリサインでは、クラウド型WAFを1ヵ月間無償で試せるトライアルサービスを提供しています。今回は、実際にトライアルサービスを利用し、WAFの機能を試してみました[2]⁠。

トライアルサービスを利用する際は、まず同社から提示されるヒアリングシートにWebサイトの情報（URLやIPアドレスなど）を記入して提出します。Webアプリケーションが稼働しているWebサーバのIPアドレスをベリサインに登録してもらえばトライアルの準備は完了です。テスト用PCのhostsファイルを書き換え、テストサイトをWAF経由で接続して、攻撃者の視点を実体験してみます。

クラウド型WAFを実際に導入してテストを実施

今回テスト用のアプリケーションにアクセスした様子が図4となります。このWebアプリケーションでは、口座番号とパスワードを使ってアクセスするようになっているのですが、実はSQLインジェクション攻撃を受ける脆弱性が残っています。

この場合、口座番号とパスワードを入力する画面があり、入力フォームで入力された口座番号とパスワードに一致するレコードがあるかどうかをSQLで確認、結果が「真」であればログインを許可する、といったしくみがフォームの裏側で動いています。この際のSQLは次のとおりです。

SELECT * FROM customer WHERE id =  and pw = ''

口座番号として「2345678⁠」⁠、パスワードに「password」などと入力されれば、SQLは次のようになり、特に問題はありません。

SELECT * FROM customer WHERE id = 2345678 and pw = 'password'

しかし、パスワードとして「'or'1' = '1」といった文字列が入力されるとどうなるでしょうか。

SELECT * FROM customer WHERE id = 2345678 and pw = ''or'1' = '1'

WHERE句に「or」が追加され、さらにそのあとに続く式は「'1' = '1'」で、結果は「真」となります。今回テストサイトにわざと残したSQLインジェクションの脆弱性は、この「真」の結果を受け付けてしまうため、IDとパスワードが一致しなくてもログインできてしまいます。

では、今度は同じテストサイトにクラウド型WAFを有効にした状態でアクセスし、前述のSQLインジェクション攻撃を行うとどうなるでしょうか。結果は図5が表示され、アクセスはできませんでした。つまり、SQLインジェクション攻撃が遮断されたというわけです。このように、Webアプリケーションに脆弱性が残っていたとしても、攻撃を意図する内容が含まれていれば通信を遮断し、不正アクセスを防いでくれます。

このSQLインジェクション攻撃以外にも、クラウド型WAFでは、クロスサイトスクリプティングやクロスサイトリクエストフォージェリ、バッファオーバーフロー、OSコマンドインジェクション、Xpathインジェクション、ディレクトリインデクシングなどさまざまな攻撃に対応しています。いずれもセキュアなコーディング、あるいはミドルウェアの適切な設定などによって防ぐことも可能ですが、アプリケーションの規模が大きくなると、脆弱性を完璧に解消することは困難です。もちろん脆弱性をなくす努力は欠かせませんが、万一に備えてこうしたソリューションを利用することで開発リスクをぐっと減らせます。

導入・運用の手間をかけずに利用できるクラウド型WAF

さらにクラウド型WAFでうれしいのは、導入時の設定がほぼ不要である点です。ソフトウェア、あるいはアプライアンスとして提供されているWAFは、導入時にパラメータの設定などが必要で、実際に利用するまでに長い時間がかかることが珍しくありません。しかし、クラウド型WAFであれば、ブラックリスト式の一般的なシグネチャが常に自動的に更新されていくので、DNSの設定変更とSSLを利用するためのサーバ証明書の登録だけで使い始められます。

運用の手間がかからないことも、クラウド型WAFの大きな魅力です。WAFを自社で運営する場合、サーバ構成を変えたり、Webアプリケーションに機能やシグネチャを追加したりするたびに、WAFやWebアプリケーションの設定を見なおさなければならないことがありますが、クラウド型WAFでは何もする必要はありません。この違いは極めて大きいでしょう（図6⁠）⁠。

ソフトウェア／アプライアンス型のWAFと比べると、クラウド型WAFにはコスト面でも大きなアドバンテージがあります。初期導入費用と利用料のいずれも割安なため、「⁠セキュリティは不安だが、コスト面での制約からWAFの導入を見送っていた」という企業でも、このクラウド型WAFであれば導入できるのではないでしょうか。

エンジニアの視点で見た場合にも、このクラウド型WAFがもたらすメリットは大きいと言えます。たとえば、SQLインジェクション攻撃を回避する方法はありますが、SQLを利用するすべてのフォームに対してSQLインジェクション対策を施し、さらに確実に対策が行われているか確認するのは容易ではありません。また、攻撃手法は日々進化しており、現在の対策が将来にわたって有効であるという保証もないわけです。

このようにWebアプリケーションの開発においては、外部からの攻撃というリスクを常に意識する必要があり、それはエンジニアにとって大きなプレッシャーとなっています。今回クラウド型WAFが実際に攻撃を防げることを確認しましたが、こうしたサービスはエンジニアの負担やプレッシャーを軽減するという意味でも有効だと感じました。

なお、ベリサインではSSLサーバ証明書[4]を使用しているサーバに、Webアプリケーションの脆弱性診断サービスを無償で提供しています。運用中のサーバであれば、まずこのサービスを利用してWebアプリケーションのセキュリティリスクを洗い出し、必要に応じてクラウド型WAFを利用してもよいでしょう。

いずれにせよ、Webアプリケーションの脆弱性対策は多くの企業にとって喫緊の課題となっています。現在運用しているWebアプリケーションに少しでも不安があれば、ベリサインのクラウド型WAFの利用を検討してみてはいかがでしょうか。