RESTサービスのセキュリティに対処する

作者 Boris Lublinsky , 翻訳者 笹井 崇司 投稿日 2010年3月22日

セクション

デベロップメント,

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

SOA ,

Webフレームワーク ,

セキュリティ ,

REST

原文(投稿日：2010/03/17)へのリンク

セキュリティがSOAの実装原則のひとつになり、RESTが急速に一般的なSOAの実装方法のひとつになるにつれ、RESTセキュリティは非常にタイムリーな話題になっているようだ。Chris Comerford氏とPete Soderling氏によると、RESTによる開発はセキュリティをうまく解決してはいないそうだ。

• RESTには所定のセキュリティ手法がないため、開発者が自前で定義してます。
• そして、急いでサービスを立ち上げようとしている開発者は、Webアプリケーションを扱うときほど真面目にはやっていないことが多いのです。

Comerford氏とSoderling氏はこう説明を続ける。RESTはHTTPをベースとしており、RESTサービスは標準的なWebアプリケーションと同じ脆弱性を持つ傾向にある。そうした脆弱性には、不適切な認証、インジェクション攻撃、クロスサイトスクリプティング、クロスサイトリクエストフォージェリなどが含まれる。これらに加えて、RESTサービスに特有のセキュリティ脆弱性もある。例えば、以下のようなものだ。

• マッシュアップに関連した問題:

  ... 複数のAPIからデータを引っ張ってくるマッシュアップでは、ユーザ名とパスワードが必要になることがあります。このとき、エンドユーザのアクセスクレデンシャルを認証するのは、マッシュアッププロバイダ任せになります。エンドユーザは、マッシュアッププロバイダがクレデンシャルを盗まないこと（あるいは、うっかり漏らさないこと）を信用しなくてはなりません。そして、APIプロバイダは、マッシュアッププロバイダがハッカーや悪意のあるユーザではなく、そのアカウントの正当なユーザを認証していることを信用しなくてはなりません。

• 未熟な草の根プロトコル:

  OAuth 1.0にはセッション固定攻撃の脆弱性があり、APIを利用するエンドユーザのアイデンティティが攻撃者により盗まれるおそれがありました。

幸運なことに、RESTサービスをセキュアにするには、多くのHTTPセキュリティプラクティスがうまく適用できる。Comerford氏とSoderling氏は以下のようなルールを推奨している。

• あなたの組織で運用しているWebアプリケーションと同じセキュリティの仕組みを、あなたのAPIでも利用しましょう。例えば、WebフロントエンドにおいてXSSフィルタリングをしているなら、あなたのAPIでもそうしなければなりません。できれば同じツールを使うのがよいでしょう。
• 独自のセキュリティをやろうとしてはいけません。ピアレビューされ、テストされているフレームワークや既存のライブラリを使いましょう。
• あなたのAPIがフリーの読み出し専用の公開APIである場合を除いて、単一鍵ベースの認証を使ってはいけません。それでは不十分です。パスワード要求を追加しましょう。
• 暗号化していない固定鍵を渡してはいけません。もしHTTP Basic認証を使って鍵をネットワーク上で送るのなら、鍵を暗号化しておきましょう。
• 理想的には、HMAC（ハッシュベースメッセージ認証コード）を使いましょう。これがいちばんセキュアです。

RESTセキュリティの状況について、K. Scott Morrison氏はさらに次のように説明している。

RESTには明確に表現されたセキュリティモデルが欠けています... その成り立ちが草の根であったためでしょう。誰の世話にもならず、ただのWebのようにやるというセキュリティへの無頓着に悩まされます... RESTスタイルに非常に人気があるのは、実装がシンプルですばやいためです。気の滅入るような複雑さとWS-*スタックのツール要求に直面しているときには、なおさらです。アプリケーションを動かすというゴールに到達するため夢中になってダッシュしているうちに、セキュリティは都合よく軽視されるか、完全に忘れ去られると考えてもよいでしょう。

Morrison氏はまた、RESTサービスをセキュアにするのは可能だと明言している。そして、SecureSpan Gatewayを使って、サービスへのアクセスにSSLとグループメンバシップに基づいたアクセス認可が必要になるようポリシーを設定することで、Comerford氏とSoderling氏が推奨するルールのいくつかを実現する方法を紹介している。さらに、SecureSpanはクロスサイトのPHPやシェルのインジェクション攻撃をスキャンするよう設定することもできるそうだ。

WS*がプロトコル非依存でWebサービス向けに厳密に構築された明確なセキュリティモデルを規定しているとのとは異なり、（現在のところ）RESTには独自のセキュリティモデルというものが存在しない。その代わりに、現在のRESTセキュリティのベストプラクティスは、既存のHTTPセキュリティの実装アプローチを活用することだ。果たして、それで十分なのだろうか？ 時がたてばわかるだろう。

• 次へ >