午前I問題
Webアプリケーションにおける「認証（Authentication）」と「認可（Authorization）」の違いに関する記述として、最も適切なものはどれか。
ア）認証はユーザが誰であるかを確認する処理であり、認可はそのユーザが特定の操作・リソースへのアクセス権限を持つかを確認する処理である。
イ）認証と認可は同一の処理を指す別名であり、どちらもパスワードの正当性を確認する処理である。
ウ）認可はユーザが誰であるかを確認する処理であり、認証はそのユーザがアクセス権限を持つかを確認する処理である。
エ）認証・認可はいずれもクライアント側で完結する処理であり、サーバ側での確認は不要である。
午前I の解答・解説を見る
正解： ア）
解説：
- ア）正解。認証（Authentication）は「あなたは誰か」を確認する処理（ID・パスワードやMFAによる本人確認）であり、認可（Authorization）は「あなたに何が許可されているか」を確認する処理（特定のリソース・操作へのアクセス権限の確認）である。両者は独立した概念であり、認証を通過しても認可のチェックが別途必要になる。
- イ）不正解。認証と認可は明確に異なる処理であり、同一視すると認証は通っているが認可が欠落しているために起こる脆弱性（IDORや権限昇格など）を見落とす原因になる。
- ウ）不正解。認証と認可の定義が入れ替わっている。
- エ）不正解。クライアント側の表示制御（メニューの非表示等）だけでは容易に迂回可能であり、認可の判定は必ずサーバ側で行う必要がある。
午前II問題
次のURLは、あるオンラインバンキングサイトの取引明細閲覧機能である。
https://bank.example.com/statement?account_id=10234ログインユーザが account_id の値を 10235 に変更してリクエストしたところ、他人の口座の取引明細が閲覧できてしまった。この脆弱性の名称として最も適切なものはどれか。
ア）クロスサイトリクエストフォージェリ（CSRF）
イ）IDOR（Insecure Direct Object Reference：安全でない直接オブジェクト参照）
ウ）SQLインジェクション
エ）セッションフィクセーション
午前II の解答・解説を見る
正解： イ）
解説：
- ア）不正解。CSRFはログイン済みユーザのセッションを悪用し、ユーザが意図しないリクエストを送信させる攻撃であり、罠サイトへの誘導が前提となる。本設問はユーザ自身がパラメータを書き換えて他人のデータへアクセスしている点で異なる。
- イ）正解。IDORは、内部的なオブジェクト識別子（本設問の
account_idのような連番ID）を外部から直接指定できる実装において、サーバ側でそのオブジェクトへのアクセス権限を確認していない場合に発生する脆弱性である。認証（ログイン）は正しく行われているが、認可（このユーザがこの口座にアクセスしてよいか）のチェックが欠落している典型例であり、OWASP Top 10では「Broken Access Control（アクセス制御の不備）」に分類される。 - ウ）不正解。SQLインジェクションはSQL文の構文を操作してDBを不正操作する攻撃であり、本設問のようにパラメータの値を正常な形式のまま変更してアクセスするケースとは異なる。
- エ）不正解。セッションフィクセーションは攻撃者があらかじめ用意したセッションIDを被害者に強制的に使わせる攻撃であり、本設問の状況とは異なる。
午後問題
G社は会員制のオンライン学習サービスを運営している。同サービスでは、会員が受講した講座の修了証（PDF）をダウンロードできる機能を提供しており、URLは次の形式である。
https://learn.example.com/api/certificates/{certificate_id}/downloadある日、会員から「他人の修了証と思われるPDFが自分のアカウントでダウンロードできた」との問い合わせが寄せられた。G社の開発チームが調査した結果、以下が判明した。
certificate_idは発行順の連番であり、第三者でも容易に推測できた- ダウンロードAPIはリクエストにログインセッションが有効であることのみを確認しており、
certificate_idが「リクエストしたユーザ自身が受講した講座の修了証であるか」の確認処理を実装していなかった - 併せて、講師アカウントに割り当てられる管理画面URL（
/admin/dashboard）についても、一般会員がログイン後にURLを直接入力するとエラーなく画面が表示され、他会員の個人情報一覧が閲覧できることが判明した
G社はこのインシデントを受け、緊急の実装修正と再発防止策の策定を行うことになった。
設問1
修了証ダウンロード機能に存在する脆弱性の名称を答えよ。また、この脆弱性が発生した実装上の根本原因を50字以内で述べよ。
設問1の解答・解説を見る
正解例：
- 脆弱性の名称：IDOR（安全でない直接オブジェクト参照）
- 根本原因：ログインの確認のみで、対象の修了証がリクエストユーザ本人のものかを確認する認可処理が欠落していたため。（50字）
解説： 本事例は認証（ログインセッションの有効性）は正しく行われているが、認可（このユーザがこのcertificate_idのリソースにアクセスする権限を持つか）のチェックが実装されていない典型的なIDORである。連番IDは推測が容易なため、他ユーザのcertificate_idを総当たりで試行されるリスクも高い。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 脆弱性名 | IDOR（安全でない直接オブジェクト参照） | 4点 |
| 根本原因 | 「認証は行われているが認可（所有者確認）が欠落」という趣旨 | 8点 |
| 根本原因（補足） | 「連番IDで推測可能」への言及 | 3点（言及があれば加点、なくても原則趣旨があれば主要点は満たす） |
「IDが推測できたこと」のみを根本原因とし、認可チェック欠落に触れていない解答は根本原因欄を3〜4点にとどめる。IDの推測困難化は緩和策であり、根本対策ではない点に留意させる。
設問2
管理画面（/admin/dashboard）が一般会員からアクセスできてしまった事象は、IDORとは異なる「権限昇格（Privilege Escalation）」の一種である垂直的権限昇格に該当する。この事象の技術的原因を述べよ。また、修了証ダウンロード機能と管理画面の双方に共通して実装すべき恒久対策を60字以内で述べよ。
設問2の解答・解説を見る
正解例：
- 技術的原因：URLを知っているだけでアクセスできる設計になっており、サーバ側でユーザのロール（権限）を確認する処理が実装されていなかった。
- 恒久対策：全てのリクエストに対しサーバ側で「ログインユーザのロール・所有権」を確認する認可チェックを一元的なミドルウェアやフレームワーク機能として強制する。（59字）
解説： 垂直的権限昇格とは、一般会員のような低権限のユーザが、本来管理者等の上位権限にのみ許可された機能・画面にアクセスできてしまう脆弱性である（これに対し、同レベルの他ユーザのリソースにアクセスできるIDORは水平的権限昇格に分類されることもある）。両者に共通する根本原因は「クライアントがURLやパラメータを知っていること」を暗黙の認可根拠としてしまい、サーバ側で明示的な認可判定を行っていない点である。恒久対策としては、個々のエンドポイントで認可チェックを都度実装するのではなく、フレームワークのミドルウェアやAPIゲートウェイなどで一元的に「デフォルト拒否（Deny by default）」の認可制御を強制する設計が有効である。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 技術的原因 | 「URLを知っていればアクセス可能」「ロール確認処理の欠落」への言及 | 6点 |
| 恒久対策 | 「サーバ側で一元的に認可チェックを行う」旨 | 6点 |
| 恒久対策（設計思想） | 「デフォルト拒否」「ミドルウェア／共通処理化」等の具体的アプローチへの言及 | 3点 |
対策が「管理画面のURLを分かりにくくする」「URLを秘密にする」といった security through obscurity（隠蔽によるセキュリティ）に留まる場合は恒久対策欄を0〜2点とする。
重要キーワード
| 用語 | 説明 |
|---|---|
| IDOR（安全でない直接オブジェクト参照） | 内部オブジェクトのIDを外部から直接指定できる実装で、所有者確認（認可）が欠落しているために他者のリソースへアクセスできてしまう脆弱性 |
| 認証（Authentication） | ユーザが誰であるかを確認する処理。ID・パスワード、MFA等で本人性を検証する |
| 認可（Authorization） | 認証済みのユーザが特定の操作・リソースへのアクセス権限を持つかを確認する処理 |
| 権限昇格（Privilege Escalation） | 本来割り当てられていない上位の権限やリソースへアクセスできてしまう脆弱性。垂直的（上位権限）・水平的（同レベル他者）に大別される |
| Broken Access Control | OWASP Top 10の分類の一つ。認可制御の不備全般を指し、IDOR・権限昇格を含む |
| デフォルト拒否（Deny by default） | 明示的に許可されていないアクセスはすべて拒否するという、安全側に倒した認可設計の原則 |
まとめ
- 午前I視点： 認証（誰か）と認可（何が許可されているか）は独立した概念であり、混同すると認可の欠落による脆弱性を見落とす。両者の定義を正確に区別する。
- 午前II視点： URLやパラメータの値をユーザが変更するだけで他者のリソースにアクセスできる状態がIDORの典型パターン。CSRFやSQLiとの識別ポイント（罠サイトの有無、構文操作の有無）を押さえる。
- 午後視点： IDOR・垂直的権限昇格ともに根本原因は「サーバ側での認可チェックの欠落」である点で共通する。恒久対策としてはID推測困難化のような対症療法ではなく、所有権・ロールを一元的にサーバ側で検証する設計を提示できるようにする。