図解：OAuth 2.0に潜む「5つの脆弱性」と解決法：デジタルID最新動向（2）（1/4 ページ）

SNSなど複数のWebサービスが連携して動くサービスは広く使われている。連携に必要不可欠なのが、アクセス権限をセキュアに受け渡すための「OAuth 2.0」といった仕組みだ。今回はOAuth 2.0に関連する代表的な5つの脆弱（ぜいじゃく）性と攻撃手法、対策についてシーケンス図を使って解説する。

[ritou（OpenID Foundation Japan），＠IT]

　OpenID Foundation Japan Evangelistのritouです。

　連載第1回では、RFCが公開されてから5年が経過した「OAuth 2.0」を振り返り、3つのユースケースを通じて、アクセス権限を受け渡す仕組みを紹介しました。OAuth 2.0はさまざまなユースケースに適用できます。その際、開発者はアプリケーションが動作する環境の特性を考慮しながら、仕様で定義されている処理を実装する必要があります。

　今回は、脆弱（ぜいじゃく）性を作り込まないOAuth 2.0の実装手法を紹介します。代表的な5つの攻撃手法と脆弱性を取り上げ、攻撃が成功する条件や攻撃の流れ、実装時の対策を紹介します。

　以下に登場する脆弱性は2種類に大別できます。まずRFC 6749（The OAuth 2.0 Authorization Framework）^＊1）に定義されている処理を正しく実装することで対策が可能なもの（攻撃1〜3）。もう1つは、それだけでは対策不可能なものです（攻撃4〜5）。

　脆弱性への対策として提案されているOAuth 2.0向けの拡張仕様や、関連するRFCも併せて紹介します。

＊1） RFC 6749の内容は、IETF（The Internet Engineering Task Force）のWebサイトで（閲覧）できる。

OAuth 2.0のセキュリティを語る上で重要な処理「OAuth Dance」

　前回紹介したようにOAuth 2.0では以下の4つの要素が登場します。この4要素の間でアクセス権限をセキュアに受け渡すことで、エンドユーザーがアプリケーションに対して、サービスAのリソースや機能の利用を許可するといった処理を進めることができます。

• Resource Owner：エンドユーザー
• Client：エンドユーザーに代わり、エンドユーザーにひも付くデータ（Protected Data）にアクセスするアプリケーション。Webアプリケーションやネイティブアプリケーションといった形態を採る
• Resource Server：Clientをエンドユーザーにひも付くデータにアクセスさせるためのAPIを提供するサーバ
• Authorization Server：Clientをエンドユーザーにひも付くデータにアクセスさせるための許可を与えるサーバ

　今回紹介する5つの攻撃と脆弱性は全てOAuth 2.0の処理の中で「OAuth Dance」と呼ばれるやりとりに関係します。RFC 6749の「4. Obtaining Authorization」で定義されている「4.1. Authorization Code Grant」と「4.2. Implicit Grant」に書かれた部分です。

　この処理をシーケンス図にまとめました（図1）。図1ではResource Server以外の3つの実体が別々です。Resource Owner（エンドユーザー）は、Client（アプリケーション）とAuthorization Server（許可サーバ）のエンドポイントを行き来します。このような動きから、この処理をOAuth ”Dance”と呼びます。

図1　「OAuth Dance」の処理の流れ

　OAuth Danceの実際の挙動は、Clientの実体ごとに3つに分かれます。

• ClientがWebアプリケーションの場合：
  Webブラウザ上のリダイレクトによって、ClientからAuthorization ServerのAuthorization Endpointに遷移する。ユーザーデータ（Protected Resource）へのアクセスを許可した後に、同様にリダイレクトによってClientに戻る
  
  
• Clientがモバイルアプリケーションの場合：
  外部Webブラウザを立ち上げる、またはWebViewを用いてAuthorization ServerのAuthorization Endpointにアクセスする。アクセスを許可した後にカスタムURIスキームを用いてClientに戻る
  
  
• ClientがテレビなどWebブラウザを持たない端末上で動作するアプリケーションの場合：
  URLやQRコードを用いて手元の端末のWebブラウザを立ち上げ、Authorization ServerのAuthorization Endpointにアクセスする。手元の端末でアクセス許可の処理が終わったらClient側の操作に戻る

　いずれもResource Ownerの同意の下でProtected ResourceへのアクセスをClientに許可するという大きな流れは同じです。しかし、単一Webブラウザ内の画面遷移、モバイルアプリケーション間の遷移、QRコード読み取りを用いたWebブラウザ起動というように、環境によって実装方法が大きく異なります。

　このように、Webブラウザ上の画面遷移やアプリケーション起動など、ユーザーの手元で行われる処理で脆弱性が生まれやすいのです。なぜなら、このような処理を意図的に中断させたり、自らの環境で実行されるべき処理を何らかの方法で他人に実行させたりする、こういったことが比較的容易なためです。

　それでは、OAuth Danceに注目しながら5つの脆弱性の内容と対策を説明しましょう。