SSTエンジニアブログ

SSTのエンジニアによるWebセキュリティの技術を中心としたエンジニアブログです。

認可リクエストとアクセストークンリクエストのredirect_uri検証によって防げる脅威

はじめに

こんにちは、脆弱性診断員の秋本です。
今回のブログもまたOAuthの話です。

先日、OAuth2.0の各必須パラメータについてまとめていたところ、アクセストークンリクエストでredirect_uriを検証する必要とは?について頭を抱えていました。
RFC6749にはその旨の記載がなく、ネットで検索をかけても明確な答えは見つからなかったのですが、なんとかこれなら妥当だろうというところまで考察できました。せっかくなので同じようなところで躓いた方の参考になればと思い今回ブログを書いた次第です。

redirect_uriパラメータについて

そもそも、redirect_uriパラメータとはクライアントのリダイレクトエンドポイント(認可コードの受け渡し先)を指定するパラメータです。
各リクエスト中でのredirect_uriパラメータの扱いはRFC内で以下のように指定されています。

  • 認可リクエストおよびアクセストークンリクエストでのredirect_uriパラメータの送信は任意
  • ただし、認可リクエストでredirect_uriパラメータが送信されていればアクセストークンリクエストでの送信も必須かつそれぞれが同一の値でなければならない

上記のように指定されている理由はRFC6749に書かれていないのですが、攻撃シナリオベースで考えてみると、オープンリダイレクタによって漏えいした認可コードを用いたアクセストークン発行を防ぐためと推測できます。なお、この脅威はRFC6819(OAuth2.0の脅威モデル)中の「Authorization "code" Leakage through Counterfeit Client」の内容と合致します。

そこで今回は、「Authorization "code" Leakage through Counterfeit Client」について、攻撃シナリオと若干の補足を交えて説明します。

Authorization "code" Leakage through Counterfeit Client とは

概要

偽装クライアントを介した認可コードの漏えいに関する脅威について書かれています。

前提条件

攻撃シナリオを設定する前に、認可リクエストとアクセストークンリクエストで送信されるredirect_uriが一致するか確認しないこと以外の必須要件は満たしているとして、以下の条件を設定します。

認可サーバの実装

  • 認可コードグラントに対応
  • クライアントのリダイレクトエンドポイントの事前登録を必須とせず、redirect_uriに対して認可レスポンスを返す
    • 認可エンドポイントにはオープンリダイレクタの脆弱性が存在する

攻撃者

アクセストークンリクエスト時にクライアント認証が行われるため、悪意のある別クライアントは攻撃者となることができません。
今回の攻撃者は、被害者と同じクライアントを利用するエンドユーザです。

攻撃シナリオ

前提条件より、認可リクエスト中のredirect_uriを改ざんすることで認可レスポンスを任意の宛先へ送信可能であることから、以下の攻撃シナリオを考えます。

  1. 攻撃者は、redirect_uriを攻撃者の管理下にあるサーバのURLに改ざんした認可リクエストを作成し、被害者に送信させます
  2. 1.の結果、被害者のブラウザには自身のリソースアクセスに対する同意画面などが表示されます
  3. 誘導されたことに気づかない被害者は、クライアントとの連携のために認可サーバでの同意処理などを行います
  4. 認可サーバは、被害者のブラウザをredirect_uriで指定されているURL(攻撃者の管理下にあるサーバ)へリダイレクトさせます。
  5. 攻撃者のサーバは、被害者の同意処理の結果である認可コードを含む認可レスポンスを受け取ります
  6. 攻撃者は自身の管理下にあるサーバのログなどから被害者の認可コードを取得します
  7. 攻撃者はクライアントとのセッションを確立後、取得した認可コードを認可レスポンスの形式でクライアントのリダイレクトエンドポイントへ送信します
  8. クライアントからはアクセストークンリクエストが送信されます
  9. 認可サーバは、1.のredirect_uri(攻撃者の管理下にあるURL)と8.のredirect_uri(クライアントのリダイレクトエンドポイント)が一致するかの検証を行わないため認可コードとアクセストークンの交換を行います
  10. 9.の結果、被害者のリソースにアクセス可能なアクセストークンが発行されます

一連の流れを図にしました。

f:id:sstakimoto:20210623181452p:plain
攻撃の流れ

この攻撃シナリオ通りにいけば、最終的に攻撃者はクライアント経由で被害者のリソースにアクセスすることが可能となります。
クライアントがフォトストレージへのアクセスを要求していた場合、被害例として、フォトストレージ内の画像の漏えい・破壊・改ざんが考えられます。

対策

参考までに、RFC6819に記載されている対策を一部抜粋しました。

  • 認可リクエスト時に指定されたリダイレクトURI認可コードを紐づけ、 トークンエンドポイントで送られてくるリダイレクトURIが一致するか検証する
  • 認可サーバはリダイレクトURIの事前登録およびその検証を必須とする

まとめ

タイトルに書いた認可リクエストとアクセストークンリクエストでのredirect_uri検証によって防げる脅威とは、オープンリダイレクタによって漏えいした認可コードを悪用したアクセストークンの発行のことであると考察できます。実際にシナリオが考えられる、およびRC6819の対策に一致することからおおむね妥当であろうと思われます。
今回の攻撃シナリオは、つまり「偽装クライアントを介した認可コードの漏えい」を防ぐためには、 そもそもオープンリダイレクタの脆弱性がなければ…といった内容でした。redirect_uriの検証は、特定の脆弱性の対策というよりは、オープンリダイレクタによる被害の緩和策といったところでしょうか。

参考文献