OAuth で state パラメーターを使わなかった場合に起きうることの例

oauth security api

Authlete Inc. で事業開発（営業）を担当している 岸田 と言います。前回、イギリスの銀行 API での UX について翻訳してみましたが、今回はもう少し技術よりの話をしたいと思います。

先週、社内の Slack 上で、下記のブログが流れてきました。

medium.com

API を公開するサービス自体の脆弱性と、API を利用する側の実装不備を利用した攻撃に関してです。今回の話の中心である state パラメーターについては、その必要性含めいろいろお問合せいただくことも少なくないですし、また、私自身ちょっと理解するのに苦労したので、簡単にまとめてみたいと思います。

報告されている脆弱性

ブログで報告されている脆弱性をまとめるとこんな感じです。

  1. OAuth 2.0 を実装し、API 経由で別サービスにファイルを共有可能なサービスを想定する。そのサービスでは、{{constructor.constructor(‘alert(1)’)()}}.jpg といった名前のファイルをアップロード可能だと仮定する。
  2. 次に、上記の API を利用する別のサービス側（クライアント側）があり、{{constructor.constructor(‘alert(1)’)()}}.jpg といった名前のファイルをアップロード可能（＝ファイルをアップロードした本人に対して Cross-site Scripting / XSS 攻撃が可能）で、かつ、そのサービスが state パラメーターの検証をしていない（＝Cross-site Request Forgery / CSRF 攻撃対策をしていない）と仮定する。
  3. 攻撃者は上記の脆弱性を組み合わせて、標的のユーザーに XSS 攻撃を仕掛ける事が可能となる。具体的には、まず、攻撃者がXSS 攻撃可能なファイルを自分の Protected Resource にアップロードする。次に、2 のサービスを利用する標的ユーザーに対して、CSRF 攻撃を仕掛ける（リンクが仕込まれた画像付きのメールなどを送る）。標的となったユーザーが上記リンクを実行した場合、上記のファイルがアップロードされた攻撃者の Protected Resource へのアクセス権を付与され、ファイルが共有され、XSS 攻撃が実行される。

ちょっとわかりにくいですが、少し具体的に説明すると、多少はわかりやすくなるかもしれません。

  1. Dropbox のようなクラウドストレージサービス A があり、そのサービス A では{{constructor.constructor(‘alert(1)’)()}}.jpg という名のファイルがアップロード可能な状態にある。API を公開していて、OAuth を実装し、state パラメーターにも対応している（リクエスト中に state が含まれている場合、認可レスポンスでそのまま値を返す状態にある）。
  2. アプリ A と連携し、保存されたファイルにアクセスするサードパーティアプリ B では、CSRF 対策がなされていない。例えば、「state パラメーターをそもそも認可リクエストに含めていない」、「認可リクエストに state パラメーターを設定しているものの、サービス A の認可サーバーから返される認可リクエスト中の state パラメーターとの検証を実施していない」、「認可レスポンス中に state が含まれていれば検証するが、含まれていない場合は検証しない（ブログで例として挙げられているのはこのパターン）」といった実装になっている。
  3. 上記の脆弱性に気づいた悪意のある攻撃者が、サービス A の自身のアカウントにファイルをアップロードし、アプリ B を利用していると思われるユーザーに、CSRF 攻撃が仕込まれた画像付きのメールを送りつける。サービス A の利用者で、誤ってそのメールを開いてしまった者は、仕込まれた XSS が作動してしまう。

上記では、ブログ同様、ファイル共有サービスを例にしてみましたが、画像ファイルをAPI経由で共有しうるサービスは対象になると思いますし、2 のstate パラメーターに関しては、API 利用者全てが対象となる話です。

対策

これら攻撃を防ぐためには、上に示したようなファイル名のファイルをアップロードできないようにすることももちろんですが、API を利用するクライアント側で state パラメーターの利用・検証をする事がまず第一歩かと思います。

なお、state パラメーターを利用する意味を理解されたい方は、下記の二つのリソースをお勧めいたします（私はこれを理解するのに苦労しました）。

図解：OAuth 2.0に潜む「5つの脆弱性」と解決法

OAuth / OpenID Connectを中心とするAPIセキュリティについて

ポイントは、

OAuth 2.0ではCSRF攻撃の目的が多少異なります。標的となったユーザーに対し、攻撃者が自らのProtected Resourceにアクセスする許可を与えることを意味します。

という点かと思います。

以上。

宣伝

弊社では、弊社サービス Authlete だけでなく、OAuth や OpenID Connect 関連のコンサルティングサービスも提供させていただいております。ご興味のある方は、sales@authlete.com までお問い合わせください。