実務で使えるペネトレーションテスト大全

RBAC / ABAC の誤実装パターン

本章では、API における権限管理の代表的なモデルである RBAC（Role-Based Access Control）と ABAC（Attribute-Based Access Control）を前提に、典型的な誤実装パターンと Pentest の検証観点を整理する。

本章のゴール

  • 前提：認証と認可の切り分け（Part 2）と、API の典型リスク（BOLA 等、Part 4-2）を把握している。
  • 到達目標：RBAC / ABAC の誤実装パターンを説明し、複数アカウントでの差分比較と期待ポリシーの棚卸しを中心に、アクセス制御の欠落を検証できる。
  • 対応演習：exercises/crapi/ 等で複数ロール／複数ユーザーを用意し、同一 API のレスポンス差分を比較して、アクセス制御の成立条件（所有者・ロール・スコープ等）を整理する。
    起動手順は 付録「演習環境クイックスタート」 を参照し、観察結果は 学習ログテンプレート（Burp Academy / 演習） に記録する。

RBAC / ABAC の概要

  • RBAC（ロールベースアクセス制御）
    ユーザーにロール（役割）を付与し、ロールごとに許可される操作を定義するモデル。例：USER、ADMIN、READ_ONLY など。
  • ABAC（属性ベースアクセス制御）
    ユーザー属性、リソース属性、環境属性（アクセス元 IP、時間帯など）を組み合わせたポリシーに基づき、アクセス可否を判断するモデル。例：department == "sales" AND resource.owner == user.id など。

実システムでは、RBAC をベースとしつつ、一部の重要操作に ABAC 的条件を追加するハイブリッドな設計も多い。

図4-4: 認可判定（RBAC / ABAC）の判断点（概要）

flowchart LR
    Client[クライアント] --> API[API エンドポイント]
    API --> AuthN[認証（トークン検証）]
    AuthN --> AuthZ[認可判定（RBAC / ABAC）]
    AuthZ -->|許可| Handler[処理]
    AuthZ -->|拒否| Deny[拒否（403 等）]
    AuthZ --- Policy[ポリシー/権限マトリクス]
    AuthZ --- Ctx[コンテキスト（ユーザー/リソース属性等）]

図4-4 のように、API の各エンドポイントで「認証」と「認可判定」を分離し、ポリシー/権限マトリクスとコンテキストに基づいて判定できる構造にすると、エンドポイント追加時のチェック漏れを抑制しやすい。

適用範囲と前提条件

RBAC / ABAC の診断では、まず「どの属性をサーバ側の正とみなすか」を明確にする必要がある。典型的には、次の 3 点を先に整理しておくと、観察結果を誤読しにくい。

  • 権限の根拠
    ロール、所属組織、所有者、時間帯、接続元ネットワークなど、アクセス可否を左右する属性が何かを整理する。
  • 属性の取得元
    IdP が発行したトークンの検証済みクレーム、サーバ側 DB の所有者情報、運用で管理される権限マスタなど、「改ざん前提で扱わない情報源」を確認する。
  • 拒否時の期待動作
    403 Forbidden を返すのか、404 Not Found で秘匿するのか、監査ログに何を残すのかを事前に把握する。

特に ABAC では、クライアントが送信した JSON ボディや画面上の表示状態をそのまま信頼せず、サーバ側で確定した属性に基づいて判定する必要がある。Pentest でも、まずは要求仕様・ロール表・権限マトリクスを確認し、「本来どう拒否されるべきか」を定義してから差分観察に入ると、再現性の高い所見にまとめやすい。

典型的な誤実装パターン

Pentest で頻出する誤実装パターンには、次のようなものがある。

  • クライアント信頼型の権限管理
    • フロントエンドの UI でボタン表示を制御しているだけで、バックエンドでは権限チェックが行われていない
    • クライアントが保持するロール表示や未検証の属性値をそのまま利用し、サーバ側で権限の正当性を検証していない
  • 不完全なロールチェック
    • 一部のエンドポイントでは管理者専用のはずが、ロールチェックが実装されていない
    • 新しく追加された API に対し、既存の権限チェックが適用されていない
  • コンテキストを考慮しない RBAC
    • ロールだけでアクセス可否を決定し、「自分自身のリソースにのみアクセスできる」という制約がない
    • 結果として、一般ユーザーでも他人の情報を参照・更新できてしまう（BOLA と表裏一体）
  • ポリシーの複雑化による抜け漏れ
    • 多数のロールや条件が増える中で、否定条件や例外ルールの組み合わせにより意図しない許可が発生する

これらは単独で発生するとは限らず、「UI 側の表示制御に依存していた結果、新設 API だけ権限ミドルウェアを通っていない」といった複合要因で露呈する場合も多い。したがって、Pentest では個別リクエストだけでなく、同じ業務機能を実装する複数エンドポイント間で判定が揃っているかも確認対象となる。

テスト戦略

RBAC / ABAC を対象とした Pentest では、次の戦略を取ると効率的である。

  • シナリオベースでロールと操作を整理する
    • 「一般ユーザーが他人の注文を閲覧できない」「営業部だけが特定のレポートを閲覧できる」など、期待されるポリシーをテスト観点としてリスト化する
  • 複数アカウントで同一リクエストを再現する
    • Burp のセッション処理や複数ブラウザを活用し、異なるユーザーで同一 API を呼び出し、レスポンス差分を比較する
  • トークン表現とサーバ側判定の整合性を確認する
    • JWT の role / scope クレームやセッション内フラグを参照している場合は、署名検証・発行者検証・サーバ側の再評価が行われているかを、許可済み環境で診断する
  • 拒否時の副作用も確認する
    • 403 / 404 の返し分け、監査ログの記録、部分的なデータ露出の有無を確認し、単なる許可・拒否だけでなく運用上の検知可能性も評価する

図4-5 は、認可テストで頻出する「同一リクエストを複数アカウントで再現し、レスポンス差分を比較する」手順を、所見化まで含めて俯瞰したものである。報告では、期待ポリシー（本来どうあるべきか）と、観測結果（実際にどうなったか）を対応付けて示す。

図4-5: 認可テストにおける差分比較（概要）

flowchart LR
    Req[同一リクエスト\n（URI/メソッド/パラメータ）] --> Replay[再現\n（Burp Repeater 等）]

    A[アカウントA\n（ロール/属性）] --> Replay
    B[アカウントB\n（ロール/属性）] --> Replay

    Replay --> RA[レスポンスA\n（Status/Body）]
    Replay --> RB[レスポンスB\n（Status/Body）]
    RA --> Diff[差分比較\n（期待ポリシーと照合）]
    RB --> Diff
    Diff --> Finding[認可不備の所見化\n（成立条件/影響/根拠）]

API Security Top 10 の BOLA / BFLA（Broken Function Level Authorization）などと重ね合わせて評価すると、報告時の整理がしやすい。

初学者向けの最小例

最小例として、「注文 API に対する参照・更新権限」を考える。ここでは攻撃手順ではなく、期待ポリシーと観察ポイントの整理方法に絞る。

ロール / 条件 GET /api/v1/orders/{orderId} PATCH /api/v1/orders/{orderId} 観察時の着眼点
一般ユーザー（自分の注文） 許可 許可 所有者判定がサーバ側で行われるか
一般ユーザー（他人の注文） 拒否 拒否 403 または 404、本文に他人の情報が混ざらないか
サポート担当 許可 拒否 閲覧専用ロールが更新 API にも誤適用されていないか
管理者 許可 許可 管理者権限の範囲が仕様書と一致するか

このようなマトリクスを先に作成しておくと、Burp Suite やブラウザで同一リクエストを比較した際に、「何が差分で、何が仕様どおりか」を切り分けやすい。初学者は、まず次の 4 項目を 1 行ずつ学習ログに残すとよい。

  • 使用したアカウント種別（所有者、非所有者、管理者など）
  • 対象エンドポイントと操作（参照 / 更新 / 削除）
  • 期待結果（許可 / 拒否、想定ステータスコード）
  • 実観測結果（レスポンス、画面表示、監査ログの有無）

この最小例は、所有者制約を伴う一般的な業務 API を想定している。バッチ API や管理画面専用 API のように利用主体が限定される場合は、「誰が呼び出せるか」「どの経路から到達できるか」を別途定義する必要がある。

改善提案の方向性

Pentest の結果として RBAC / ABAC の問題を報告する際は、単に「権限チェックが不足している」と指摘するだけでなく、次のような改善方向を示すと有用である。

  • 権限チェックを共通ミドルウェアやポリシーエンジンに集約し、エンドポイントごとの書き忘れを防ぐ
  • ロール表や権限マトリクスを維持し、API 仕様と一貫性を取る（Part 7 のテンプレートと連動）
  • JWT 検証やロール評価ロジックをライブラリ化し、各サービスが独自実装しないようにする
  • 拒否時の監査ログ、アラート条件、レビュー手順を定義し、運用時に権限逸脱を追跡できるようにする

これにより、単発の脆弱性修正ではなく、権限管理の仕組みそのものの強化に繋げやすくなる。

次に読む Part

本章のポイント

  • RBAC / ABAC の診断では、ロールや属性の種類だけでなく、「どの情報源をサーバ側の正とみなすか」と「拒否時の期待動作」を先に定義することが重要である。
  • 典型的な誤実装は「クライアント信頼」「エンドポイントごとのチェック漏れ」「所有者などコンテキスト欠落」「ポリシー複雑化による意図しない許可」であり、複数要因が同時に現れる場合も多い。
  • テストはシナリオ（期待ポリシー）ベースで観点化し、複数アカウントの差分比較、拒否レスポンスと監査ログの確認、権限マトリクスとの照合によって診断する。
Edit this page on GitHub