はじめに
Ajax（Asynchronous JavaScript + XML）やマッシュアップ（Mashup）に代表されるWeb 2.0技術は、そのリッチで使いやすいユーザーインターフェイスや高速なレスポンス性から、現在のWebアプリケーション開発のトレンドの一つとなっています。現在注目を集めているクラウド・コンピューティングにおいても、雲（＝インターネット）から提供されるサービスを使用したり連携するために、AjaxやJavaScriptはよく用いられます。しかし、セキュリティーの観点から見ると、これらWebアプリケーションやその主要な実行環境環境であるWebブラウザーには、さまざまなセキュリティー上の脅威が存在します。図1は、IBMのセキュリティ部門の一つであるISSが公開しているセキュリティ脅威のトレンドとリスクに関するレポート2008年版によるもので、ISSが検知したWebアプリケーションに関する脆弱性の件数がここ数年で非常に増加していることを示しています。
また、同レポートでは、発見されたWebアプリケーションの脆弱性の数が、他のプラットフォームの脆弱性の数を上回ったことも報告されています。このことは、Webアプリケーションが、ITシステムの中核を担うようになってきたと共に、セキュリティー上の脅威とそれに起因するリスクが高まっていることを意味しています。
Webアプリケーションが、企業レベルの使用に耐えるためには、信頼性やセキュリティーと言った基盤技術が必要です。この記事では、Webアプリケーションを開発あるいは使用する際のセキュリティー上の問題点や対策、筆者が取り組んでいる研究開発プロジェクトなどについて紹介します。
Web 2.0に特有のセキュリティーがあるのか？ と聞かれることがよくあります。Webアプリケーションのセキュリティーを高めるための情報やツールを提供しているOWASPプロジェクト（Open Web Application Security Projectでは、2004年と2007年にWebアプリケーションにおける10個のセキュリティー上の脅威をあげています。2007年のリストは次のようになっています。
- クロスサイトスクリプティング（Cross Site Scripting, XSS）
- インジェクション攻撃
- 悪意を持ったファイルの実行
- 安全でないオブジェクトの直接参照
- クロスサイトリクエストフォージェリー
- 情報漏洩と不適切なエラー処理
- 認証とセッション管理の不備
- 安全でない暗号データ保存
- 安全でない通信
- URLによるアクセス制限の不備
後で紹介するクロスサイトスクリプティングや、スクリプトやSQLコードを注入し実行させるインジェクション攻撃、意図しないWebページの書き込みや商品購入を引き起こすクロスサイトリクエストフォージェリー（Cross Site Request Forgery, CSRF）など、Web 2.0アプリケーションに多く見られる脅威が上位に来ていますが、クロスサイトスクリプティング、インジェクション攻撃は、2004年のTop 10リストにも入っています。つまり、攻撃手法そのものは、Web 2.0技術が普及する前後で大きく変化している訳ではなく、Webを取り巻く環境やアプリ開発のあり方が変化したことにより、より深刻さを増してきたと言えるでしょう。
Web 2.0の特徴の一つは、コンテンツが、多くの場合匿名のユーザによって生成され、別のユーザー群によってアクセスされることです。コンテンツの量が膨大になると共に、質という面では、企業や信頼される情報源からのコンテンツとは異なり、必ずしも正確な情報ばかりとは限りなくなってきています。信頼できるWebサイトを騙るフィッシング攻撃も問題になってきていますし、WikiやSNSなどでの誹謗中傷が社会的な問題になっているのはご存じの通りです。また、コンテンツに悪意を持ったJavaScriptコードやマルウエア（malware）が含まれる危険性も増加しています。このようにWeb上のコンテンツがコモディテイー化し、信頼性や価値が相対的に低下していることが、前述のさまざまな脆弱性を引き起こす原因の一つとなっています。
また、これらのコンテンツを扱うWebアプリケーション構築のあり方も変わりつつあります。例えば、Webブラウザは、静的なHTML文書の閲覧環境から、動的なコンテンツやWebアプリケーションの実行プラットフォームへと役割を変えつつあります。DojoなどのJavaScriptベースのライブラリーが充実し、ロジックがクライアント（＝Webブラウザ）側でも動くようになったことで、従来サーバー側を主に守っていればよかったセキュリティーが、クライアント側でのプログラム実行にも注意を払う必要が出てきています。Webブラウザのセキュリティーモデルは、従来からの静的なHTML文書の閲覧環境を想定したものであり、Webアプリケーションのセキュアな実行環境としては不十分です。Webブラウザの実装が多数存在し、さらにバージョンの違いによって変わる振る舞いが、セキュリティ的にも問題になります。Flashなどブラウザ上で動くプラグインのバリエーションを考えると、開発者は膨大な組み合わせのクライアント環境を仮定しないといけません。
さらに、Web 2.0技術を用いることで、Webブラウザ上に複数の機能やAPIをコンポーネント化してマッシュアップすることが可能になりました。SaaSやクラウド・コンピューティングの普及と相まって、企業アプリにおいても、社内のコンポーネントとWeb上のコンポーネントをマッシュアップするケースが今後増えていくと考えられます。これらのコンポーネントは、セキュリティー的には、異なるドメインに属するものであり、信頼できるものとそうでないものをどのように組み合わせるかは非常に重要な問題です。信頼できないコンポーネントが悪意を持ったスクリプトを含んでいると、信頼できるコンポーネントをコントロールし、重要な情報を盗み出される可能性があります。
以降、Webアプリケーションのセキュリティーについて、いくつかのトピックを紹介します。
XSSとコンテンツのフィルタリング
クロスサイトスクリプティング（以降、XSSと呼ぶ）は、動的にHTML文書を生成するWebアプリケーションにおいて、悪意を持ったスクリプトを外部から与えることで、HTML文書内に挿入させ、このスクリプトを実行させる攻撃方法です。前述したように、一般ユーザーが生成したコンテンツが多数流通している現在、悪意を持ったスクリプトコードを容易に埋め込むことが可能になりました。図2に、SNS（Social Networking Service）を例にとってXSS攻撃に例を示します。
- 攻撃者は、投稿入力画面から、正規のデータ（例. 日記）に、悪意を持ったスクリプトを挿入します。
- 入力された内容は、SNSサーバーに送られます。
- SNSサーバー側では、入力された内容にスクリプトが注入されていないかをチェックしますが、攻撃者は、後述する手法などを使ってこの処理をバイパスします。
- チェックをすり抜けたスクリプトが、SNSサーバー上のデータベースに格納されます。
- 一般（攻撃対象）ユーザーが、日記やコメントを読むためにSNSサーバーにアクセスします。
- 攻撃者の日記やコメントを読む過程で、悪意を持ったスクリプトが一般ユーザーのWebブラウザーで実行されます。
ここで注意したいのは、SNSサーバーそのものは一般的には信頼できるドメインにあることです。現行のWebブラウザーでは、怪しいサーバーのURIを指定することで、そのドメインからダウンロードされたJavaScriptを実行しないという設定が可能ですし、NoScriptといったFireFoxプラグインもよく使われます。しかし、現在のWebアプリケーションの多くが、JavaScriptを用いたWebページから構成されているため、JavaScriptの実行を禁止すると、そのWebアプリケーションを正しく動かすことはできなくなってしまいます。
また、上で示した手順2）のように、多くのWebアプリケーションでは、ユーザーが入力した文字列をサーバー側でチェックして、悪意を持ったスクリプトを検出しています。ただ、攻撃者は、さまざまな手法を用いてそれを免れようとします。
例えば、入力として
今日は天気です<img src="javascript:alert('hello');">
<script>alert('hello again')</script>
。
という日記のテキスト文字列を受け取ることを考えましょう。単純にはそのテキストをスキャンし、"javascript:"と言うという文字列があるかどうかを検査するプログラムを書くことは容易です。ただ、次のような文字列が入力だったらどうでしょう。
今日は天気です
<img src="jav ascript:alert('XSS');">
。
驚くべきことに、上のスクリプトを実行してしまうブラウザ（特定のバージョン）があるのです。また、
今日は天気です src=javascript:alert('XSS')> 。
これは、各文字をUTF-8エンコーディングしたものです。ブラウザによっては、この符号化された文字列をアスキーコードに変換して実行するものがあります。これらの場合、単純に"javascript:"があるかどうかをチェックしても意味がありません。
ha.ckers.orgのXSS Cheat Sheetでは、単純な検証処理をすり抜けるための手法が収集され、対応するWebブラウザーの種類と共に記載されています。新しいバージョンのWebブラウザでは、これらの問題に対応しているものが多いですが、ユーザーが使用しているWebブラウザーがいつも最新だとは限らないため、注意が必要です。
XSSを防ぐための解決策の一つとして、筆者が所属する研究チームでは、設定したフィルタリングルールに基づいて、HTML, JSON, RSS/ATOM Feedデータから、JavaScriptコードを除去するツールActive Content Filter（ACF）を開発し、いくつかのIBM製品に提供しています。例えば、軽量な次世代WebアプリケーションプラットフォームであるProject Zero（製品版はWebSphere sMash）では、Webコンテンツに対してACFを適用することが可能です。また、Project Zero/WebSphere sMashでは、XSSとならんでWebアプリケーションに対する脅威として知られているクロスサイトリクエストフォージェリー（Cross Site Request Forgery, CSRF）を防ぐためのモジュールも含まれています。また、同様のツールとして、前述のOWASPが、AntiSammyというツールを公開しています。また、PerlやPHPなどのプログラミング言語では、文字列をエスケープしたりサニタイズする関数やライブラリーが提供されており、それらをうまく使うことで、脅威を軽減することが可能です。ただ、攻撃者はあの手この手を使って、これらの処理を無効化しようとするので、できるだけ新しいバージョンを使ったり、最新の情報を知るなどの努力が必要です。
脆弱性チェックツールIBM Rational AppScan
Webアプリケーションに対する脅威は、もちろんXSSだけではありません。さまざまな脅威を念頭に置きながらWebアプリケーションを構築することは困難です。セキュリティーのエキスパートではない開発者を支援するための環境やツールはいくつかありますが、ここでは、Rational AppScanという製品を紹介します。
AppScanは、既に構築されているWebアプリケーションに対し、さまざまな攻撃の組み合わせを自動生成・実行し、その結果をレポートすることができます。AppScanに、Webアプリケーションのtop画面のURLを入力すると、そのページをスキャンし、たどることができるページを収集していきます。得られたページのスキャンをさらに行い、ページ集合を作ります。それらに、例えばJavaScriptを埋め込んだ入力を自動生成し、サーバーに送信します。結果として受け取るHTML文書を解析し、攻撃が成功したかどうかをチェックします。既存のWebアプリケーションに対し、URL経由でネットワーク越しに解析を行いますので、簡単に既存のWebアプリケーションの脆弱性チェックが可能ですし、テスト段階からこのツールを用いることで、将来的なリスクを軽減することができます。図3にAppScanの画面のスナップショットを示します。
スキャン結果には、発見された脆弱性の詳細と、対策方法が含まれており、この結果を基に、アプリケーションを修正しよりセキュアにすることができます。
また、2008年には、Javaで書かれたWebアプリケーションに対し、ソースコードを解析することで脆弱性を検知する製品AppScan Developer Edition（DE）も発売されています。
マッシュアップにおけるセキュリティー
マッシュアップでは、Web APIやウィジットとして定義されたコンポーネントを組み合わせることで、複合アプリケーションを構成します。例えば、Google Mapなどの地図と、店舗データをマッシュアップしたり、乗り換え案内と社内の精算システムとを組み合わせたりといった例が典型的です。現在は、Web上のコンポーネントを組み合わせることが多いですが、SaaSやクラウドコンピューティングが注目を集めている今、企業内のコンポーネントとWeb上のコンポーネントを組み合わせるシナリオが増えてくると思われます。社内のコンポーネントと、Web上のコンポーネントでは所属するセキュリティードメインが異なりますし、攻撃されたWeb上のコンポーネントが、マッシュアップされた企業内コンポーネントを攻撃するという危険性も同時に増えてくるでしょう。
マッシュアップの形態には、サーバーサイドマッシュアップ（図4）と、クライアントサイドマッシュアップ（図5）の2種類が考えられます。サーバーサイドマッシュアップは、アプリケーションサーバーがサービスを行うサーバーに接続し、サービスを統合します。この場合、クライアントは、仲介・統合するアプリケーションサーバーに接続するため、もともとのサービスを行うサーバーを関知することができません。言い換えると、あるデータが信頼できるサーバーから来ているのか、そうでないかが、クライアント側ではわからないということになります。
一方、クライアントサイドマッシュアップは、Webページ上で複数のサーバーからのサービスを呼び出し、Webブラウザー上で実行します。そもそも、Webブラウザでは、異なるドメインのサーバーからダウンロードされたJavaScriptは、ダウンロード元のサーバーにしかアクセスすることができないというSame Origin Policyが実装されているのですが、いくつか抜け道があります。例えば、<script>タグのsrc属性に別のサイトのダウンロードページを指定することで、異なるサイトのJavaScriptファイルを読み込むことができます。この場合、異なるメインのコードが混在することになり、悪意を持ったスクリプトを含んだコンポーネントから他のコンポーネントへアクセスし、重要な情報を盗み出すことが可能になります。
IBMでは、日本IBM 東京基礎研究所の筆者らのチームとアメリカにあるワトソン研究所が共同で、Secure Mashupと呼ばれる、コンポーネント同士のセキュアな情報アクセス制御技術を研究開発しています。Secure Mashup技術を用いることで、コンポーネントAからBへのアクセスは許すが、BからAへのアクセスは許さないといった、情報流の制御が可能になります。現在Secure Mashupは、JavaScriptで実装されており、Ajax技術の普及を目指す業界団体であるOpenAjax Allianceに寄贈されています。コンポーネントが直接通信するのではなく、ハブと呼ばれるコミュニケーションコンポーネントを介した通信を行うことで、きめ細やかなアクセス制御を実現しています。
おわりに
Web 2.0技術を用いたWebアプリケーションにまつわるセキュリティの問題をいくつか取り上げ、紹介しました。セキュリティーには100%安全ということはまずありません。いくつかの対策を組み合わせて100%に近づけていくことが必要です。Webアプリケーションの開発者はセキュリティーの専門家ではないことが多いでしょうから、必要最低限の知識と定評のあるセキュリティ製品やツールをうまく使いこなしていくことが重要だと思います。
