会員APIの診断：オブジェクト・機能レベルの認可不備とJWT検証

Web APIの認可に関する次の記述を読んで，設問に答えよ。

F社は，従業員120名の食品会社であり，ミールキットの定期配送サービス（以下，Mサービスという）を運営している。会員数は約30万人である。会員は，スマートフォン用のアプリケーションプログラム（以下，会員アプリという）又はWebブラウザで動作するシングルページアプリケーション（以下，会員SPAという）から，注文の確認，配送日の変更，会員情報の変更を行う。F社の運用担当者は，社内向けのSPA（以下，運用画面という）から会員の照会などを行う。また，配送を委託しているD社の配送員は，配送委託先向けのポータル（以下，配送ポータルという）から配送先の一覧を参照する。

会員アプリ，会員SPA及び運用画面は，いずれも会員API（https://api.mealbox.example）を呼び出す。配送ポータルは，配送API（https://partner-api.mealbox.example）を呼び出す。会員API及び配送APIは，F社の開発チーム（6名）が開発・運用している。

〔認証とアクセストークン〕

会員，運用担当者及び配送員は，F社の認可サーバ（https://auth.mealbox.example）で認証を受け，JSON Web Token（以下，JWTという）形式のアクセストークンを取得する。アクセストークンの有効期間は15分である。認可サーバは，RSA鍵だけを保有し，全てのアクセストークンをRS256で署名する。署名の検証に用いる公開鍵は，認可サーバのJWKSエンドポイントで公開している。アクセストークンのペイロードには，利用者の識別子（sub），ロール（role）などが含まれる。roleの値は，会員が member，運用担当者が operator，配送員が partner である。各APIは，リクエストのAuthorizationヘッダーに含まれるアクセストークンを検証し，subの値によって利用者を識別する。アクセストークンの例を図1に，会員APIのトークン検証設定を図2に示す。

図1　アクセストークンの例（Base64URLデコード後）

(例1) 会員アプリで取得したアクセストークン
ヘッダー  : {"alg":"RS256","typ":"JWT","kid":"k2026a"}
ペイロード: {"iss":"https://auth.mealbox.example","sub":"M0012345",
             "aud":"https://api.mealbox.example","role":"member",
             "iat":1789000000,"exp":1789000900}

(例2) 配送ポータルで取得したアクセストークン
ヘッダー  : {"alg":"RS256","typ":"JWT","kid":"k2026a"}
ペイロード: {"iss":"https://auth.mealbox.example","sub":"D0000777",
             "aud":"https://partner-api.mealbox.example","role":"partner",
             "iat":1789000100,"exp":1789001000}

図2　会員APIのトークン検証設定（現行）

token_verify:
  jwks_uri  : https://auth.mealbox.example/.well-known/jwks.json
  issuer    : https://auth.mealbox.example   # issが一致しないトークンは拒否
  algorithms: from_header                    # トークンのヘッダーのalgに従って検証
  audience  : (設定なし)                     # audは検証しない
  leeway_sec: 60                             # exp検証の時刻ずれの許容(秒)

会員APIの仕様の抜粋を表1に示す。

表1　会員APIの仕様（抜粋）

注記 order_idは，注文ごとに1ずつ増える8桁の整数である。項番5の確認コードは，再設定の申込み時に会員のメールアドレスに送られる6桁の数字（000000〜999999）であり，有効期間は10分である。

〔API診断の実施〕

F社は，新しい会員アプリの公開を前に，セキュリティ診断会社のG社に会員APIの診断を委託した。診断は検証環境で行い，G社の診断員は，F社が用意した二つのテスト用会員アカウント（会員A，会員B），テスト用配送員アカウント及びテスト用運用担当者アカウントを使用した。診断結果を表2に示す。

表2　診断結果（抜粋）

G社は，診断報告書で，各指摘にOWASP API Security Top 10（2023年版）の分類を併記した。No.1はAPI1:2023 Broken 【 a 】 Level Authorization，No.2はAPI5:2023 Broken 【 b 】 Level Authorization，No.3はAPI3:2023 Broken Object 【 c 】 Level Authorizationに当たる。No.6については，10分間に試行できる回数から計算すると，攻撃者が会員の確認コードを総当たりで当てる確率は，1回の申込み当たり約【 d 】%であり，申込みを繰り返せば更に高くなると指摘した。

〔修正方針の検討〕

F社のJ課長と開発チームのKさんは，診断報告書を基に修正方針を検討した。2週間後に新しい会員アプリの公開とキャンペーンを控えており，開発チームの工数は限られている。

No.1について，Kさんは，①order_idを推測困難なランダムな値（UUID）に変更すれば解決すると提案した。しかし，G社は，これだけでは不十分だと指摘した。そこで，表3の修正案を比較した。

表3　No.1の修正案

No.2について，Kさんは，会員アプリには運用画面へのメニューがないので影響は小さいと考えていた。しかし，J課長は，攻撃者は会員アプリを使わずにAPIを直接呼び出せると指摘し，②会員API側で確認を追加することにした。ただし，G社は，③No.4が残ったままでは，②の確認を追加しても効果がないと説明した。

No.4とNo.5については，図2の設定を，algorithmsを [ 【 e 】 ] に，audienceを 【 f 】 に変更することにした。

No.3について，会員情報を変更する処理の実装を図3に示す。

図3　表1の項番3の実装（抜粋）

// PATCH /v1/members/me
const member = await Member.findById(token.sub);
Object.assign(member, req.body);   // ④リクエストの項目をそのまま会員レコードに反映
await member.save();
res.json(member);                  // 会員レコードの全項目を返す

No.6について，Kさんは，⑤APIの手前のリバースプロキシで，送信元IPアドレスごとに1秒当たり10回を超えるリクエストを拒否する案を示した。G社は，この案だけでは不十分であり，確認コード単位の対策も必要だと助言した。