Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

title: “RBAC / ABAC の誤実装パターン” part: “Part 4” chapter: “4-4”

RBAC / ABAC の誤実装パターン

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

本章のゴール

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

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

典型的な誤実装パターン

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

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

テスト戦略

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

  • シナリオベースでロールと操作を整理する
    • 「一般ユーザが他人の注文を閲覧できない」「営業部だけが特定のレポートを閲覧できる」など、期待されるポリシーをテスト観点としてリスト化する
  • 複数アカウントで同一リクエストを再現する
    • Burp のセッション処理や複数ブラウザを活用し、異なるユーザで同一 API を呼び出し、レスポンス差分を比較する
  • トークンやクッキーのロール情報を操作する
    • JWT の role / scope クレーム、セッション内のフラグなどを変更し、サーバ側の検証有無を確認する（署名検証が前提）

図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）などと重ね合わせて評価すると、報告時の整理がしやすい。

改善提案の方向性

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

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

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

次に読む Part

本章のポイント

  • RBAC / ABAC を前提に、実システムではハイブリッド設計が多いことを踏まえて、権限管理の成立条件を整理する。
  • 典型的な誤実装は「クライアント信頼」「エンドポイントごとのチェック漏れ」「所有者などコンテキスト欠落」「ポリシー複雑化による意図しない許可」である。
  • テストはシナリオ（期待ポリシー）ベースで観点化し、複数アカウントの差分比較とトークン操作（署名検証が前提）で検証し、改善は権限チェックの集約と運用可能な権限マトリクス整備へ繋げる。