V4: アクセス制御

管理目標

認可とはリソースの使用を許可された人にのみアクセスを許可するという概念です。検証対象のアプリケーションが以下の上位要件を満たすことを確認します。

• リソースにアクセスする人はそうするために有効なクレデンシャルを保持しています。

• ユーザは明確に定義された役割と権限のセットに関連付けられています。

• 役割と権限のメタデータはリプレイや改竄から保護されています。

セキュリティ検証要件

V4.1 一般的なアクセス制御設計

#	説明	L1	L2	L3	CWE
4.1.1	特にクライアント側のアクセス制御が存在し、それが回避される可能性がある場合には、アプリケーションは信頼できるサービス層に対してアクセス制御規則を適用する。	✓	✓	✓	602
4.1.2	アクセス制御で使用されるすべてのユーザ属性とデータ属性およびポリシー情報は、特に認可されていない限りエンドユーザが操作できない。	✓	✓	✓	639
4.1.3	最小特権の原則が存在する。ユーザは特定の権限を持つ機能、データファイル、URL、コントローラ、サービス、およびその他のリソースにのみアクセスできるようにすべきである。これはなりすましや権限昇格に対する保護を意味する。 (C7)	✓	✓	✓	285
4.1.4	[削除, 4.1.3 と重複]
4.1.5	例外が発生した場合も含めて、アクセス制御がセキュアに失敗する。 (C10)	✓	✓	✓	285

V4.2 操作レベルのアクセス制御

#	説明	L1	L2	L3	CWE
4.2.1	機密データおよび API が、他人のレコードの作成や更新、全員のレコードの閲覧、すべてのレコードの削除など、レコードの作成、読み取り、更新、削除を目的とする非セキュア直接オブジェクト参照 (Insecure Direct Object Reference, IDOR) 攻撃に対して保護されている。	✓	✓	✓	639
4.2.2	認証済みの機能を保護するために、アプリケーションやフレームワークが強力な CSRF 対策メカニズムを実施している。また、有効な自動化対策や CSRF 対策が未認証機能の保護を実施している。	✓	✓	✓	352

V4.3 その他のアクセス制御に関する考慮事項

#	説明	L1	L2	L3	CWE
4.3.1	管理インタフェースは不正使用を防ぐために適切な多要素認証を使用している。	✓	✓	✓	419
4.3.2	明確に必要でない限りディレクトリ参照が無効化されている。さらに、アプリケーションは Thumbs.db, .DS_Store, .git, .svn などのファイルやディレクトリメタデータの漏洩や開示を許すべきではありません。	✓	✓	✓	548
4.3.3	アプリケーションには低価値システムに対する追加の認証 (ステップアップ認証や適応認証) がある、また、アプリケーションのリスクと過去の不正行為により不正対策制御を実施するために、高価値アプリケーションに対する役割の分離がある。		✓	✓	732

参考情報

詳しくは以下の情報を参照してください。

• OWASP Testing Guide 4.0: Authorization

• OWASP Cheat Sheet: Access Control

• OWASP CSRF Cheat Sheet

• OWASP REST Cheat Sheet