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

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

[ritou（OpenID Foundation Japan），＠IT]

前のページへ 1|2|3|4 　　　　　　

【攻撃手法5】IdP Mix-Up Attack

　悪意のあるAuthorization Serverが、他のAuthorization Serverの発行したAccess Tokenなどを奪おうとする攻撃「IdP Mix-Up Attack」について、最後に紹介します^＊5）。

＊5） OAuth 2.0のAuthorization ServerはIdentity Providerと呼ばれることもあるが、ここではAuthorization Serverという用語を使って説明する。

　攻撃を受ける前提条件は次の3つです。

Clientはソーシャルログイン機能のように、複数のAuthorization Serverと接続しており、その中の1つが攻撃者の管理下にある
ClientはそれぞれのAuthorization Serverに対して共通のRedirect Endpointを用いたAuthorization Requestを送る。CSRF対策のためのstateパラメーターを用いてAuthorization Serverの識別を行う（攻撃2や攻撃4の対策として取り上げたAuthorization Code Flowを用いるものとする）
Clientと標的となるResource Ownerの間のセキュアではない（例えばHTTPSを利用していない）通信を、攻撃者が中継できる

　攻撃の流れは次の通りです。

標的となるResource Ownerが悪意のないAuthorization Server（HAS：Honest Authorization Server）にAuthorization Requestを送ろうと試みる。これを攻撃者がプロキシ機能（図8中のAttacker's Proxy）により検知する
攻撃者はClientに対して悪意のあるAuthorization Server（AAS：Attacker Authorization Server）へのAuthorization Requestを要求する（図8中の青い矢印）
攻撃者はHAS向けのAuthorization RequestのstateパラメーターをAAS向けのものと置き換え、標的となるResource OwnerをHASに送る（赤い矢印）
標的となるResource OwnerはHAS上でProtected Resourceへのアクセス許可を行い、ClientにAuthorization Responseが送られる（緑の矢印）
ClientはAuthorization Responseに含まれるstateパラメーターにより、Authorization ResponseはAASが作成したものと判断する
ClientはAASに対してHASから発行されたAuthorization Codeなどを含むAccess Token Requestを送る（紫の矢印）
AASは受け取ったAccess Token RequestをHASに送ることにより、標的となるResource OwnerのAccess Tokenなどを取得可能

図8　IdP Mix-Up Attackの攻撃の流れ

　IdP Mix-Up Attackの対策は2つあります。

Authorization ServerごとにRedirect EndpointをClientが分け、stateパラメーターを用いたAuthorization Serverの判定を避ける
Authorization ResponseにAuthorization Serverなどの情報を含め、Clientはその情報を用いて処理の分岐を行う

　この対策はRFC 6749（The OAuth 2.0 Authorization Framework）には、定義されていません。2番目の手法については拡張仕様が提案されています。

　IdP Mix-Up Attackが成立する前提条件はやや複雑です。しかし複数のAuthorization Serverとソーシャルログインで連携しているClientの開発者は、万が一いずれかのAuthorization Serverが悪意のある振る舞いをした場合、どのような影響があるかを想定しておく必要があるでしょう。

日本語ドキュメントでさらに深く知る

　今回はOAuth 2.0に関連する代表的な5つの脆弱性と攻撃について紹介しました。攻撃1～3は攻撃者がResource Ownerの立場で攻撃しますが、攻撃4はClient、攻撃5ではAuthorization Serverの立場を採っています。幾分イメージしにくいものもあったかもしれません。

　このような脆弱性を見ると「OAuth 2.0は危ない」と感じるかもしれません。これに対して、有識者が拡張仕様の検討を含めて対策を周知しています。

　例えばOAuth 2.0に関する脆弱性と対策についてまとめたドキュメントもRFC 6819としてまとまっています（OAuth 2.0 Threat Model and Security Considerations）。

　今回紹介したCSRF対策やCovert Redirect（オープンリダイレクター）対策に関する記載もあります。OAuth 2.0の実装に関わる開発者の皆さまには参考になるでしょう。

　ボリュームのある英語のドキュメントを読むのは大変だという声もあります。そこで、OpenIDファウンデーション・ジャパンのWebサイトにRFC 6819の日本語訳を用意しました（RFC 6819 - OAuth 2.0 Threat Model and Security Considerations 日本語訳）。

　今回紹介した内容と併せて、OAuth 2.0の安全な実装の手助けになれば幸いです。

　次回はOAuth 2.0をMicroservicesや分散システム向けに適用するための拡張機能を取り上げる予定です。