知っておきたいクラウドのリスクとセキュリティ 第4回

Webセキュリティの専門家がクラウドのセキュリティを斬る！

SaaS利用時には要注意！Webアプリのセキュリティ

本稿では、SaaSのようなWebアプリケーションのセキュリティ対策の現状と最近の話題を紹介する。ここでは、「暗号の2010年問題」などWebアプリケーションを利用するに当たって注意すべき点をまず解説し、続いてユーザーとしても知っておきたいSaaS業者側のセキュリティを紹介しよう。

暗号の2010年問題

　ECサイトでのネットショッピングや会員制サイトのユーザー登録を行なうなど、クレジットカード番号や個人情報を登録するような場面では、SSLサーバー証明書の利用は必須となっている。もちろん、多くのSaaSでは利用時のログインにSSLサーバー証明書が使われている。このSSLサーバー証明書の公開鍵暗号方式の主流であった1024ビットRSA暗号が、米国国立標準技術研究所によって2010年以降の使用を禁止される。これが「暗号の2010年問題」だ。

画面1　米国の国立標準技術研究所（National Institute of Standards and Technology：NIST）は、工業技術などの規格の開発や標準化を行なう組織。米国連邦政府が使用する暗号規格の制定も担当する

　PC用のWebブラウザでは、早々に2048ビットRSA暗号に対応している。ところが、携帯電話のブラウザでは、2048ビットRSA暗号に対応していない端末がまだまだ使われているのが現状である。日本では内閣官房情報セキュリティセンター（NISC）が2013年までの猶予期間を設けているので、2013年まで段階的な対応が可能である。しかし、早期に対応が完了したWebサイトや米国のWebサイトなどには、携帯電話のブラウザでは、2011年以降SSL接続ができなくなるケースが発生する。

　Webサイト事業者の実在性を証明するEV SSL証明書でも、鍵交換アルゴリズムが2048ビットRSA暗号に対応していないものは2010年12月31日で失効する。そのため、古い携帯電話のWebブラウザからは接続できなくなる可能性がある。余談だが、筆者が以前使用していた携帯電話は2048ビットRSA暗号に非対応だが、現役で使っている人をよく見かける。

　また、SSLv2やSSL 128ビット以下の低い強度の暗号化アルゴリズムをサポートしているWebサーバーやWebブラウザ（Internet Explorer 5.5や6.0）も、まだ現役で使用されている状況は見受けられる。そのため、Webサイト事業者による早急なWebサーバーの設定見直しや、ユーザーへの啓蒙による最新のWebブラウザへのアップグレードなどの対策が求められる。

　もちろん、古いバージョンのWebブラウザを使うユーザーをサポートし続けるために、Webサイトを危険にさらす方法もある。しかし、リスクが大きいため、高い強度暗号化アルゴリズムのみ使用するように設定変更することをお勧めしたい。その他にもSSL関連では、TLSのリネゴシエーション機能に問題があり、中間者攻撃により暗号化された通信内容を盗聴されたり改ざんされたりする危険性がある脆弱性「CVE-2009-3555」が、2009年11月に発見されている。もしWebサーバーの設定に不安があるのなら、脆弱性診断を受けてみるのも1つの方法だ。

「他のユーザーになりすませる」古くて新しい問題

　2010年10月に米国で開催されたセキュリティカンファレンス「ToorCon 12」にて発表された、「FireSheep」というツールが話題になっている。このツールはFirefoxの拡張機能として提供されており、TwitterやFacebookなどといったWebサイトにおいて容易に他のユーザーへ「なりすまし」できるというものだ。

　なりすましを成功させるために、Webサイトに存在する脆弱性が利用されている。だが、特に新たな種類の脆弱性が発見されたというわけではない。暗号化されていない通信路に流れるセッション情報を盗聴し、取得した値を利用してWebサイトにアクセスする「セッションハイジャック」を使う手法だ。つまり、これを使ったなりすましは、その手法自体には目新しさはないのだ。

　この手法をとるためには、従来はネットワークのスニッフィングソフトを利用して通信路を流れるセッション情報を抜き出し、さらにその値を利用してWebサイトにアクセスするという、手間が必要だった。ところが、FireSheepはブラウザの拡張機能という形で提供され、わずか数クリックで攻撃が成功してしまう（図1）。この手軽さゆえ、注目されたといえよう。

図1　FireSheepではいとも簡単に他のユーザーになりすましができてしまう

　セッションハイジャックが成功してしまうのは、そもそもWebサイトのセッション管理の方法に問題があるからであり、攻撃される可能性は従来から存在していた。FireSheepは海外製ということもあって、そのツールによってセッションハイジャックが行なわれるサイトは海外のものばかりとなっている（設定により追加は可能）。しかし、日本のWebサイトにおいても同様の状況が当てはまるのではないかと筆者は考えている。

　セキュアスカイ・テクノロジー（SST）では、これまで数多くのWebサイトの脆弱性診断を実施してきた。その中で、次のようなケースが散見される。ログイン処理や個人情報の登録・変更処理といった重要な情報を入力・送信する場面では、HTTPS（SSL）による暗号化通信を利用しているにもかかわらず、ログイン後のセッション管理を行なっている部分で（暗号化をしない）HTTPを使っているケースだ。

　このようなケースが、必ずしもすべて危険だというわけではない。しかし、HTTPで通信しているセッション情報のみで、HTTPSで通信している個人情報にもアクセスできるとしたら、結局はHTTPSを使う意味が薄れてしまう。極論すればすべての通信をHTTPSにするという話にもなりかねないが、そうすると、暗号化処理を行なうインフラコストが増大してしまう。そこで、個人情報へのアクセスを行なうWebサイトでは、HTTPSとHTTPの使い分けと合わせて、セッション情報もsecure属性の付いたもの／付いていないものを使い分ける対策など、何らかの工夫が必要になる。

　Webブラウザは、secure属性のついたセッション情報をHTTPでの通信時には送信せずに、HTTPSのときのみ送信する。そのため、セッション情報が盗聴されるリスクがなくなるというメリットがある。したがって、重要な情報へアクセスできるセッション情報には、secure属性を付けておくことを推奨する。

　SQLインジェクションやクロスサイトスクリプティングといった代表的な脆弱性の影に隠れてしまっているような感もあるが、セッション関連の脆弱性についてもきちんとした対策が必要なのは間違いない。

　Webサイト事業者側がセキュリティ対策という点で十分な責任を果たしていない状況に、ユーザーの立場から危機感を感じたことがFireSheepのようなツールを開発する動機となったようだ。このやり方についての是非はあるにせよ、ユーザー側がWebサイト事業者側に対してセキュリティ対策を求めていくことで、Webサイト事業者側の取り組みに影響を与えられるという側面もある。実際に、FireSheepのセッションハイジャックのターゲットとなったいくつかのWebサイトでは、今回の件をきっかけにして対策を実施してきているようである。

　クラウド技術の普及によって、大きなコンピューティングパワーとスケーラビリティを低コストで手に入れられるようになった。今後も、この基盤を利用して多くのWebサイトがインターネット上に出現することになると考えられる。しかし、セキュリティという観点では、従来のWebサイトで必要となっている脆弱性対策を行なわなければならないという点では、クラウドになっても何ら変わるところはないのである。

（次ページ、「SaaS事業者のセキュリティ意識の推移」に続く）