検索
連載

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

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

Share
Tweet
LINE
Hatena

 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
図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つの脆弱性の内容と対策を説明しましょう。

       | 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

Security & Trust 記事ランキング

  1. セキュリティ専門家も「何かがおかしいけれど、攻撃とは言い切れない」と判断に迷う現象が急増 EGセキュアソリューションズ
  2. 英国政府機関が取締役にサイバーリスクを「明確に伝える」ヒントを紹介
  3. 人命を盾にする医療機関へのランサムウェア攻撃、身代金の平均支払額や損失額は? 主な手口と有効な対策とは? Microsoftがレポート
  4. AIチャットを全社活用している竹中工務店は生成AIの「ブレーキにはならない」インシデント対策を何からどう進めたのか
  5. MicrosoftがAD認証情報を盗むサイバー攻撃「Kerberoasting」を警告 検知/防御方法は?
  6. 「このままゼロトラストへ進んでいいの?」と迷う企業やこれから入門する企業も必見、ゼロトラストの本質、始め方/進め方が分かる無料の電子書籍
  7. SBOMの本質を大阪大学 猪俣教授が語る――「うちのソフトは大丈夫なんです」とユーザーにどう証明する?
  8. Google、「パスキー」のアップデートを発表 新たに導入された「パスワードマネジャーPIN」とは?
  9. 「Amazonプライム感謝祭」に関するフィッシング攻撃を確認、注意すべき7つのポイントとは チェック・ポイント・ソフトウェア・テクノロジーズ
  10. 「PC操作が不能になる手口」が増加中 IPAが推奨される対処法を紹介
ページトップに戻る