認証は「誰か」までしか守らない ── オブジェクト単位の認可漏れが IDOR ──

【社内セキュリティ勉強会 #1 認証・認可】の登壇資料です。

認証を通過しても、オブジェクト単位で認可を確認しなければ他人のデータは見えてしまう——「認証≠認可」を手を動かせる形で持ち帰る回です。

find($id) で取ったレコードを所有チェックせず返す、よくある実装がどう IDOR（安全でない直接オブジェクト参照 / BOLA / Broken Access Control）を生むのか。
URL の ID を1つ書き換えるだけの疑似デモで穴を体感し、「直接参照+認可チェックの欠落」という設計の言葉に翻訳。
最後に FuelPHP（認可がコントローラに散る＝分散・暗黙）と Laravel の Gate/Policy（1箇所に集約＝集中・明示）を対比します。

▼ 持ち帰る結論
① 認証は本人確認まで
② 取得できる ≠ 見てよい
③ 認可は1箇所に明示集約

想定読者は「認証は書けるが認可は曖昧だった、ちょっと前の自分」。全6回シリーズの第1回。

Transcript

1. 認証は「誰か」までしか守らない ── オブジェクト単位の認可漏れが IDOR ── 認証を通過しても、Object単位で認可しなければ他人のデータは見える(認証≠認可) 社内セキュリティ勉強会 #1 認証・認可 / 2026-07-16
2. 昔は「ログインさえ通れば安全」と思っていた 認証は気にした。でも認可は意識していなかった ❖ find($id) で取ってきたものを、そのまま返していた ❖ 認証は気にしたが、認可を意識していなかった ❖ 「認可のテスト、書いてますか?」
3. 今日のゴール: 認証≠認可を、手を動かせる形で持ち帰る 認証を通過しても、Object単位で認可しないと他人のデータは見える(認証≠認可) 第1回 認証・認可 第2回 インジェクション /SSRF 第3回 XSS/CSRF /セッション 第4回 暗号/シークレット 第5回 ネットワーク/WAF 第6回 ログ/追跡 想定読者は「ちょっと前の自分」。今日は認可を中心に、認証は要点だけ扱います。 話者: kuroneko
4. 今日の道順と、持ち帰る結論3つ 道順: 用語 → 認証の限界 → デモ(IDOR) → 設計論 → フレームワーク 結論① 認証は本人確認まで 結論② 取得できる≠見てよい 結論③ 認可は1箇所に明示集約
5. 01 識別・認証・認可は別物
6. 識別 → 認証 → 認可 の3段階 本人確認(認証)の先に、許可(認可)がある STEP 1 識別 Identification 識別子を付与する STEP 2 認証 Authentication 識別子の正当性を検証 STEP 3 認可 Authorization 許可された操作だけを実行 認証が済んでも、認可は別物 ── 今日の主役は③認可
7. アクセス制御=アクセスを「選択的に」制限すること 目的は機密性・完全性・可用性(C/I/A)の維持 ❖ アクセス制御=資産/リソースへのアクセスを選択的に制限する方法 ❖ 目的=機密性・完全性・可用性(C/I/A)の維持 ❖ 認証・認可はアクセス制御を実現する手段
8. 門番(Reference Monitor)が抜けると他人のデータに届く Subject →[Reference Monitor]→ Object(Operation を実行) 誰が (Subject) アクセスを試みる主体 (ユーザー/プロセス) 門番 (Reference Monitor) Object単位で認可を確認 抜けると誰でも到達できる 何に (Object) 保護対象の資産(データ・API)
9. 認可設計の土台は「最小特権=デフォルト拒否」 迷ったら拒否 ── 許可を明示した操作だけを通す ❖ 「明示しない限り拒否」がIDOR対策の思想的な核 ❖ 許可を明示した操作だけを通す=デフォルト拒否 原則 内容 職務の分離 (SoD) 1人に権限を集中させない 知る必要性 (Need-to-know) 必要な情報だけに限定 最小特権 (POLP) 必要最小限の権限のみ付与
10. 02 認証は「誰か」までしか守らない
11. 認証は本人確認まで ── 3要素で確かめる 多要素でも AiTM・MFA疲労で破られうる 要素 英語 例 知識 Something you know パスワード 所有 Something you have ハードウェアトークン スマートカード 生体 Something you are 指紋・顔
12. 認証を通過した「後」が、今日の主戦場 認証OK=本人だと分かっただけ。本人でも他人のデータを見てよいわけではない ❖ 認証OK=「本人だと分かった」だけ ❖ 本人でも、他人のデータを見てよいわけではない(認証≠認可) ❖ 【核心】認証を通過しても、Object単位で認可しなければ他人のデータは見える
13. 03 認可の穴を、実演で見せる: IDOR
14. デモで見るもの: URLのIDを1つ書き換えるだけ 参考実例: http://billpay.com/api/v1/cust/459(顧客IDをURL直接指定) STEP 1 正規ログイン 認証は通っている STEP 2 IDを書き換え /api/users/123 の 123 だけ STEP 3 レスポンスを見る 他人のデータが出るか 注目 ── 認証は正しいのに、他人のデータが出るか?
15. 自分のID(123)なら、正しく返る 正常系 ── 自分のIDなら期待どおり(値は説明用フィクスチャ) ❖ 自分のID(123)なら期待どおりの結果 ❖ レスポンスに自分の氏名・メール ❖ ここは普通=次に他人のIDへ書き換える GET /api/users/123 { "id": 123, "name": "山田太郎", "email": "taro@example.com" }
16. ★ 124 に変えると、他人のデータが見えた 山場 ── 認証は通ったまま、他人の氏名・メールが返る(値は説明用フィクスチャ) ❖ IDを他人のもの(124)に書き換えるだけ ❖ 認証は通ったまま、他人の氏名・メールが返る ❖ 一切の権限チェックが無い GET /api/users/124 ← 124 に変更 { "id": 124, "name": "佐藤花子", "email": "hanako@example.com" }
17. 抜けていたのは「Object単位の認可」 認証OK≠認可 ── 門番(Reference Monitor)が消えた状態 誰が (Subject) 認証は通過した 正規ユーザー/攻撃者 門番=無い! Reference Monitor の チェックが欠落 何に (Object) 他人のデータへ直達 =水平権限昇格
18. 04 なぜ穴は生まれるのか: オブジェクト単位の認可
19. IDOR=直接参照 + 認可チェックの欠落 さっきのデモの一般化 ── 実例 http://billpay.com/api/v1/cust/459 ❖ APIの引数にオブジェクトの直接参照(ID)が使われる ❖ そのオブジェクトにアクセス制御(認可)が課されていない ❖ 攻撃者はパラメータ値を総当たりで権限外データにアクセスできる
20. 別名: IDOR / BOLA / Broken Access Control 用語が分裂して混乱しがちだが、根は同じ(直接参照+認可欠落) 名称 出自 関係 IDOR 古典/Web全般で使われる名称 本体は同じ BOLA OWASP API Security Top 10 API1:2023 オブジェクト単位の認可の失敗 Broken Access Control OWASP Top 10(Web)A01:2021 (2017 5位→1位) IDOR を例として内包
21. 認可には4種類ある: 集中 / 分散 / 暗黙 / 明示 2軸=どこで判断するか(集中 分散)× 明示的に要求するか(暗黙 明示) ❖ この4分類が、後のフレームワーク対比の評価軸 になる 分類 意味 集中型 認可を1箇所で判断 分散型 認可を各所に散らして判断 暗黙的 認可を明示的に要求しない 明示的 認可を明示的に要求する
22. 明示的認可を怠るとIDOR になる 暗黙は危険・明示は安全 ── 設計思想の結論 暗黙的認可(危険) find($id) は認可が無くても取得できてしまう 明示的認可(安全) 明示しない限り拒否。所有チェックを明示的に要求 「取得できる」は「見てよい」ではない ── 明示しない限り拒否
23. 05 フレームワークでどう守るか
24. FuelPHP: 行レベルの認可は自前実装しがち Auth パッケージ=認証+グループ/ロールベースの ACL 認可はある ❖ Auth パッケージ=認証+グループ/ロールベースの ACL 認可はある ❖ 無いのは「これはあなたのデータか」= Object(行)単位の認可の仕組み ❖ 判断がコントローラに散る=分散・暗黙になりやすい
25. この穴あきコードが、さっきのデモの正体です before(FuelPHP 1.x)── 所有チェックが無い ❖ get_view($id) が Model_User::find($id) して返すだ け ❖ 「これはあなたのものか」を確認していない= 所有チェック無し ❖ 実装全文は Appendix A5 // FuelPHP 1.x Controller_Rest public function get_view($id = null) { $user = Model_User::find($id); // ↑ ID で取得するだけ・所有未確認 return $this->response($user); // ↑ 認可チェック無し → IDOR }
26. Laravel: Gate/Policy で認可を1箇所に集約 Policy=モデルごとに認可ロジックを集約する置き場。コントローラは尋ねるだけ ❖ Policy=モデルごとに認可ロジックを集約する置 き場 ❖ コントローラは「認可を尋ねるだけ」 ❖ Policy が門番=Reference Monitor の実体 php artisan make:policy \ UserPolicy --model=User
27. Policyコード例: 所有者だけが見られると宣言 明示的認可の実物 ── view(User $user, User $model): bool ❖ UserPolicy::view(User $user, User $model): bool ❖ return $user->id === $model->id;(自分自身だけ閲 覧可) ❖ 所有リソースなら $resource->user_id === $user- >id も同じ考え // app/Policies/UserPolicy.php class UserPolicy { // 自分自身だけ閲覧可(明示的認可) public function view( User $user, User $model): bool { return $user->id === $model->id; } }
28. RMB は「解決」だけ ── 認可は別で書く after ── RMBは解決のみ・認可は走らない。Gate::authorize を足して初めて403 ❖ Route Model Binding は ID→モデルを解決するだ け=認可は走らない ❖ Gate::authorize('view', $user) を足して初めて他人 なら403 ❖ ルートで守るなら ->can('view', 'user') ミドルウェ アでも可 class UserController extends Controller { public function show(User $user) { // RMB=ID解決のみ・認可は別 Gate::authorize('view', $user); return $user; // 他人なら403 } } // route: ->can('view', 'user')
29. 対比: 分散・暗黙 vs 集中・明示 「どこで判断するか・明示するか」で穴の生まれやすさが決まる 観点 FuelPHP(1.x) Laravel(13.x) 認可の置き場所 コントローラに散る Policy に集約 集中-分散 分散 集中 暗黙-明示 暗黙になりやすい 明示 IDORの起きやすさ 起きやすい 起きにくい
30. レガシーでも、認可を1箇所に寄せられる 「FuelPHPだから無理」で終わらせない ── 明示的認可を強制する設計は作れる ❖ 共通の認可ヘルパ/ベースコントローラでチェックの型を1つに揃える ❖ フレームワークが無くても「明示的認可を強制する設計」は作れる ❖ まず認可を1箇所に寄せる
31. 脅威→対策: 認可の穴は「明示」で塞ぐ 全編の背骨を1枚に ── 脅威の地図の上に対策を並べ直す 脅威 対策(明示で塞ぐ) IDOR / BOLA(直接参照+認可欠落) Object単位の明示的認可を1箇所(Policy/共通ヘルパ)に 認証と認可の混同 認証=本人確認まで/認可=別途 Object単位で確認 暗黙的認可(取得できる=見てよい) デフォルト拒否+明示的認可の強制
32. Take-away: Object単位の認可漏れは丸見え 核心: 認証≠認可 ── これだけ持ち帰ってください 結論① 認証は本人確認まで 結論② 取得できる≠見てよい 結論③ 認可は1箇所に明示集約
33. Next action: 明日からできる3つ 抽象で終わらせず具体で ── 特に「他人のIDで叩いて403」のテストが効く 1. チェックを足す 一覧・詳細APIに「これはあ なたのものか」を追加 2. 1箇所に寄せる 認可を Policy / 共通ヘルパに 集約する 3. テストを書く 他人のIDで叩いて403を確認 する
34. 次回予告 ── 第2回はインジェクション/SSRF この後は質疑・議論(20分)へ ❖ 第2回=インジェクション系+SSRF ❖ 認証の深掘りは CySec 復習ログ #6 ❖ 関連スライド・記事は近日公開予定 ❖ この後は質疑・議論へ
35. A1: 認証の深掘りは CySec 復習ログ #6 へ 本編で圧縮した認証の受け皿 ❖ MFA攻撃=AiTM / MFA疲労(キーワードのみ) ❖ NIST SP800-63 の AAL(キーワードのみ) ❖ 詳細は CySec 復習ログ #6
36. A2: アクセス制御モデル(MAC/DAC/RBAC/RB-RBAC) 権限を誰が・どう付与するかで分類する モデル 説明 例 MAC 管理者のみ権限付与 SELinux DAC 所有者が決定(ACL) UNIX/Linux/Windows RBAC 役割で付与 - RB-RBAC ルールで動的付与 -
37. A3: 認証の5要素(3要素+2) 本編の3要素に Somewhere you are / Something you do を足した5要素 要素 英語表記 例 知識 Something you know パスワード 所有 Something you have トークン・スマートカード 生体 Something you are 指紋・顔 場所 Somewhere you are 位置情報/GPS 行動 Something you do 署名・打鍵の癖
38. A4: IDOR以外のAPI攻撃(CCT の8項目) IDOR はこの8項目の2番目(★)── この順・この表記 # API攻撃(CCT・この順) 1 ファジング 2 安全でない直接オブジェクト参照(IDOR)★ 3 無効な入力攻撃 4 インジェクション攻撃 5 安全でないSSL設定 6 安全でないセッション/認証の処理 7 ログイン/クレデンシャルスタッフィング攻撃 8 API DDoS攻撃
39. A5-1: FuelPHP 自前実装(before)全文 本編と同じコード ── fuel/app/.../api/users.php(FuelPHP 1.x) ❖ Controller_Rest の get_view($id) が find($id) して 返すだけ ❖ 認可チェックが無い=IDOR(所有未確認) ❖ レスポンス例=デモの他人データ(id:124 佐藤花 子) class Controller_Api_Users extends Controller_Rest { public function get_view($id = null) { $user = Model_User::find($id); return $this->response($user); // ↑ find だけ・所有未確認 → IDOR } }
40. A5-2: Laravel Policy+コントローラ(after)全文 本編と同じコード ── 明示的認可(Laravel 13.x) ❖ UserPolicy::view で所有者だけ許可(明示的認可) ❖ コントローラで Gate::authorize('view', $user) → 他人なら403 ❖ ルートで守るなら ->can('view', 'user') // UserPolicy.php (Laravel 13.x) public function view(User $user, User $model): bool { return $user->id === $model->id; } // UserController.php public function show(User $user) { Gate::authorize('view', $user); return $user; // 他人なら403 } // route: ->can('view', 'user')
41. A6: 用語の系譜(出典リンク集) IDOR / BOLA / Broken Access Control の出自と出典 名称 出自 出典 IDOR 古典/Web(CCTで扱う) CCT eBook 書籍263/PDF274 BOLA OWASP API Security Top 10 API1:2023 owasp.org/API- Security/editions/2023/en/0xa1-broken- object-level-authorization/ Broken Access Control OWASP Top 10 A01:2021 owasp.org/Top10/2021/A01_2021- Broken_Access_Control/