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

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

[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　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　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