連載
» 2017年10月24日 05時00分 公開

デジタルID最新動向(2):図解:OAuth 2.0に潜む「5つの脆弱性」と解決法 (3/4)

[ritou(OpenID Foundation Japan),@IT]

【攻撃手法3】Covert Redirect

 次に紹介する「Covert Redirect」もImplicit Grant Flowに関する脆弱性を突く攻撃です。

 攻撃について説明する前に、図2で登場したものの、詳細には触れていなかったAuthorization Responseについて触れておきましょう。Implicit Grant FlowではAuthorization Responseの形式が、例えば以下のようなURLになります*3)

 http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

*3) RFC 6749(The OAuth 2.0 Authorization Framework)の「4.2.2. Access Token Response」より引用

 パラメーターを後ろに従えた「http://example.com/cb」という部分を「Redirection Endpoint」と呼びます。Authorization Requestのためのredirect_uriパラメーターはClientが指定します。Redirection Endpointの後半にある「access_token」や「state」などがこのパラメーターで、Fragment identifier(フラグメント識別子)として指定されています。

 問題となるのは、次のようなケースです。

  • Redirection Endpointが任意のドメインにリダイレクトできるオープンリダイレクターになっている
  • Implicit Grant Flowが利用可能であり、フラグメント識別子にAccess Tokenが含まれる
  • UserAgent(Webブラウザ)の実装により、リダイレクト時にフラグメント識別子の値を引き継ぐ

 攻撃者はオープンリダイレクターを利用して任意のURLに遷移するようなRedirection Endpointを作成、Authorization Request(URL)を作り上げます(図6中の青い矢印)。標的となるユーザーがこのURLにアクセスしてOAuth 2.0の処理を続けると、ユーザーのAccess Tokenの値を攻撃者が取得できてしまいます。

図6 図6 Covert Redirect攻撃の流れ

 この攻撃への対策は、Redirection Endpointの実装にあります。

 Client側ではOAuth 2.0の処理が終わった後に同一サービス内で前にいたページに戻るように実装することがあるでしょう。このとき、外部の任意のURLにリダイレクトされないように気を付ける、つまり一般的なオープンリダイレクター対策を行う必要があります(図6中の赤丸部分)。加えて、早めにフラグメント識別子の値を削除する対応も必要でしょう。

 Authorization Server側では、併せてAuthorization Requestのredirect_uriパラメーターのチェックを厳密に行う必要があります(青丸部分)。ドメインによる一致のみで検証すると、正しいRedirection Endpointと同一ドメイン内にオープンリダイレクターが存在した場合、そのURLが悪用されるリスクが大きくなります。

 CSRF対策と同様に、一般的なWebアプリケーションのセキュリティ対策の一環としてオープンリダイレクターが存在しないように気を付けて実装する必要があります。

【攻撃手法4】Authorization Code Interception Attack

 次にAuthorization Code Flowの利用時に起こりうる脆弱性「Authorization Code Interception Attack」について紹介します。Authorization Code FlowはToken Replace Attack(攻撃手法2)の対策として先ほど紹介しました。

 Authorization Code Flowでは、Authorization ResponseのURLにAccess Tokenではなく、Authorization Codeの値を含めます(図7中の青い矢印)。ClientはこれをAuthorization ServerのToken Endpointに送ることでAccess Tokenを取得します。

 ClientがWebサーバ上で動作するアプリケーションの場合は対策が容易です。Access Tokenを取得する際にClientを認証するための(例えば)秘密鍵を安全に管理すればよいのです。攻撃者は第三者のAuthorization Codeを取得しても悪用が難しくなります。

 攻撃が成功するのは、次のようなケースです。

  1. モバイルアプリケーションのカスタムURIスキームのように、標的となるClientと同一のRedirection Endpointによって起動するアプリケーションを攻撃者が作成する。その後、標的ユーザーの端末にインストールさせる(図7で赤い下線を引いたAttacker's Client)
  2. 標的ユーザーは標的となるClientを利用しようとして、Authorization Server上でアクセス許可を行う
  3. Authorization ServerはAuthorization ResponseをClientに送ろうとするが、攻撃者のアプリケーションが起動してしまい、Authorization Codeを横取りする(赤丸)。

 モバイルアプリケーションの場合は、攻撃者のアプリケーションが標的となるClientになりすまして、Authorization CodeからAccess Tokenを取得できてしまいます。

図7 図7 Authorization Code Interception Attackの攻撃内容

 困ったことに、RFC 6749に忠実に従って実装しても、この攻撃を防止できません。

 対策はこうです。Authorization Requestを作成したClientのみが、Authorization Responseに含まれるAuthorization CodeからAccess Tokenを取得できるようにします。そのための拡張仕様がRFC 7636(Proof Key for Code Exchange by OAuth Public Clients)としてRFC化されています*4)。RFC 7636では、Authorization RequestとAccess Token Requestに新たなパラメーターを追加しています(仕様の詳細説明は省略)。

 Clientが動作する環境により、Redirection Endpointへの遷移が保証されていない状況が考えられる場合、この攻撃を想定して対策が取られているかどうか、確認する必要があるでしょう。

*4) RFC 7636

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。