A01:2025 アクセス制御の不備 (Broken Access Control)

背景 (Background)

「アクセス制御の不備」は、OWASP Top 10 の第1位を維持しています。テストされたすべてのアプリケーションで、何らかの形でアクセス制御の不備が見つかりました。主な CWE (共通弱点一覧) には、認可されていない者への機密情報の露出 (CWE-200)、送信データによる機密情報の露出 (CWE-201)、サーバーサイドリクエストフォージェリ (SSRF: CWE-918)、およびクロスサイトリクエストフォージェリ (CSRF: CWE-352) が含まれます。本カテゴリは、収集データにおいて出現回数が最も多く、関連する CVE (共通脆弱性識別子) 数は第2位を記録しています。

スコアテーブル (Score Table)

紐付けられた CWE 数	最大出現率	平均出現率	最大網羅率	平均網羅率	平均加重悪用スコア	平均加重影響スコア	出現総数	CVE 総数
40	20.15%	3.74%	100.00%	42.93%	7.04	3.84	1,839,701	32,654

説明 (Description)

アクセス制御は、ユーザーが意図された権限を超えて行動できないよう、ポリシーを強制することです。制御に失敗すると、通常は情報の不正開示、データの改ざんや破壊、あるいは権限外のビジネス機能の実行を招きます。一般的なアクセス制御の脆弱性は以下の通りです。

最小権限の原則 (Principle of Least Privilege) への違反： 特定の機能やロールに対してのみアクセスを許可すべきところ、デフォルトですべてのユーザーにアクセスを許可している状態。
アクセス制御チェックの回避： URL（パラメータの改ざんや強制ブラウズ）、アプリケーションの内部状態、HTML ページの改ざん、あるいは攻撃ツールによる API リクエストの変更を通じたチェックの回避。
IDOR (安全でない直接オブジェクト参照) ： 一意の識別子を書き換えることで、他人のアカウントを表示・編集できる状態。
API の制御不備： POST、PUT、DELETE に対するアクセス制御が欠如した API。
権限の昇格 (Elevation of Privilege) ： ログインせずにユーザーとして行動することや、一般ユーザーが管理者権限を取得するなど、想定外の権限を得ること。
メタデータの操作： JSON Web Token (JWT) や Cookie、隠しフィールドなどの改ざん、あるいは JWT の無効化処理の悪用による権限昇格。
CORS (オリジン間リソース共有) の設定ミス： 認可されていない、あるいは信頼できないオリジンからの API アクセスを許可している状態。
強制ブラウズ (Forced Browsing) ： 認証が必要なページや権限が必要なページに対して、URL を推測して直接アクセスを試みること。

防止方法 (How to Prevent)

アクセス制御が効果を発揮するのは、攻撃者がチェック処理やメタデータを変更できない、信頼できるサーバー側のコードまたはサーバーレス API で実装されている場合のみです。

デフォルトで拒否 (Deny by Default) ： 公開リソースを除き、原則としてすべてのアクセスを拒否してください。
仕組みの再利用： アクセス制御の仕組みは一度だけ実装し、CORS の使用を最小限に抑えるなど、アプリケーション全体で再利用してください。
レコード所有権の強制： 単に作成・読み取り・更新・削除を許可するのではなく、各レコードの所有権に基づいたアクセス制御をモデル上で強制してください。
ドメインモデルでの制限： アプリケーション固有のビジネス制限要件を、ドメインモデルによって強制してください。
ディレクトリ一覧の無効化： Web サーバーのディレクトリ一覧表示機能を無効化してください。また、ファイルのメタデータ（.git など）やバックアップファイルが公開ディレクトリ内に存在しないことを確認してください。
ログとアラート： アクセス制御の失敗をログに記録し、繰り返しの失敗などが必要な場合は管理者にアラートを通知してください。
レート制限 (Rate Limits) ： 自動化された攻撃ツールによる被害を最小限に抑えるため、API やコントローラーへのアクセスにレート制限を導入してください。
セッションの無効化： ログアウト後は、ステートフルなセッション識別子をサーバー側で無効化してください。ステートレスな JWT トークンは、攻撃の機会を減らすために有効期間を短く設定してください。長期有効な JWT の場合は、リフレッシュトークンの使用や OAuth 標準に準拠したアクセス取消を検討してください。
確立されたパターンの活用： シンプルで宣言的なアクセス制御を提供する、実績のあるツールキットやパターンを使用してください。

開発者および QA 担当者は、ユニットテストおよび統合テストにアクセス制御の機能テストを組み込む必要があります。

攻撃シナリオの例 (Example Attack Scenarios)

シナリオ #1： アカウント情報へのアクセスに、検証されていないデータを使用した SQL 呼び出しが行われている。

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

攻撃者はブラウザの acct パラメータを書き換えるだけで、任意の口座番号を送信できます。適切に検証されていない場合、攻撃者は他人のアカウントにアクセスできてしまいます。

https://example.com/app/accountInfo?acct=notmyacct

シナリオ #2： 攻撃者が管理ページなどの特定の URL に対して強制ブラウズを試みる。管理ページへのアクセスには管理者権限が必要です。

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

未認証のユーザーがどちらのページにもアクセスできる場合や、一般ユーザーが管理ページにアクセスできる場合は、不備があると言えます。

シナリオ #3： アプリケーションがアクセス制御をフロントエンドのみで実装している。ブラウザ上の JavaScript により https://example.com/app/admin_getappInfo へのアクセスがブロックされていても、攻撃者はコマンドラインから直接リクエストを実行できます。

$ curl https://example.com/app/admin_getappInfo