オブジェクトレベル認可
ある REST API は GET /api/v1/orders/{orderId} で注文の明細を返す。サーバはセッションで利用者がログイン済みであることは確認するが，その orderId が当該利用者のものかは検証していない。攻撃者が自分のセッションのまま orderId を書き換え，他人の注文を閲覧できた。再発防止策として，最も適切なものはどれか。
- アリクエストごとに，認証された利用者がその orderId のオブジェクトにアクセスする権限をもつかをサーバ側で検証する。
- イorderId を連番ではなく推測困難な UUID に変更し，他人の ID を推測できないようにする。
- ウリクエストに推測困難な CSRF トークンを付与し，送信されたトークンが正しい場合にだけ処理を実行する。
- エ注文明細の応答を TLS で暗号化し，orderId が通信経路上で盗聴されないようにする。
正解と解説を見る
正解 ア
この問題の基礎知識
- 認証は利用者が誰であるかを確認することであり，認可はその利用者が対象のデータや操作に対する権限をもつかを判断することである。ログイン済みであることは，個々のデータへの権限を意味しない。
- IDOR（BOLA）は，要求に含まれる注文番号などのオブジェクトの識別子を書き換えるだけで他人のデータに到達できる，オブジェクト単位の認可の不備である。
- 識別子を推測困難にしても，有効な識別子が漏れれば認可の検査がない限りアクセスできるので，検査の代わりにはならない。
- CSRF 対策は第三者のサイトから利用者に意図しない要求を送らせる攻撃への対策であり，TLS は通信の盗聴や改ざんへの対策である。脅威ごとに有効な対策を区別する。
アリクエストごとに，認証された利用者がその orderId のオブジェクトにアクセスする権限をもつかをサーバ側で検証する。正解
原因は，認証は確認するがオブジェクト単位の認可（所有者かどうか）を検査していないことである。参照する ID ごとに利用者の権限を確かめることが直接の対策になる。
イorderId を連番ではなく推測困難な UUID に変更し，他人の ID を推測できないようにする。
ID を複雑にしても，攻撃者が有効な ID を入手すれば認可検査がない限り閲覧できる。識別子の複雑さは認可検査の代わりにはならない。
ウリクエストに推測困難な CSRF トークンを付与し，送信されたトークンが正しい場合にだけ処理を実行する。
CSRF トークンは第三者サイト経由の意図しない要求を防ぐもので，自分のセッションで ID を書き換える本事例は防げない。対象とする脅威が異なる。
エ注文明細の応答を TLS で暗号化し，orderId が通信経路上で盗聴されないようにする。
本事例は盗聴ではなく，利用者自身が ID を変えて他人のデータに到達できる認可不備である。通信路の暗号化では権限のない参照を止められない。
検証用の出典出典照合済み
OWASP Insecure Direct Object Reference Prevention Cheat Sheet ／ CWE-639 Authorization Bypass Through User-Controlled Key ／ OWASP Authorization Cheat Sheet照合の根拠（5 件）
- ア（正解）: 利用者がアクセスしようとするオブジェクトごとにアクセス制御の検査を行うのが対策である
To mitigate IDOR, implement access control checks for each object that users try to access.
OWASP Insecure Direct Object Reference Prevention Cheat Sheet · Mitigation（新しいタブで開きます） - ア（正解）: 識別子のキー値を書き換えて他人のデータに到達できる認可の不備が本事例の弱点である
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
CWE-639 · Description（新しいタブで開きます） - イ（誤り）: 推測困難な ID にしてもアクセス制御の検査は不可欠で，代わりにはならない
In some cases, using more complex identifiers like GUIDs can make it practically impossible for attackers to guess valid values. However, even with complex identifiers, access control checks are essential. If attackers obtain URLs for unauthorized objects, the application should still block their access attempts.
OWASP Insecure Direct Object Reference Prevention Cheat Sheet · Identifier complexity（新しいタブで開きます） - ウ（誤り）: CSRF は第三者が認証済み利用者のブラウザに意図しない操作をさせる攻撃で，攻撃者が自分のセッションで ID を書き換える本事例とは脅威が異なる
A Cross-Site Request Forgery (CSRF) attack occurs when a malicious web site, email, blog, instant message, or program tricks an authenticated user's web browser into performing an unwanted action on a trusted site.
OWASP Cross-Site Request Forgery Prevention Cheat Sheet · Introduction（新しいタブで開きます） - エ（誤り）: 攻撃者は認証済みの利用者自身であり，原因は認可検査の欠如なので，通信路の暗号化（盗聴対策）では防げない
It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.
CWE-639 · Extended Description（新しいタブで開きます）