[スキル名] php-auth-audit

PHP 認証メカニズム監査（Auth Audit）

PHP Web プロジェクトのソースコードを分析し、認証および認可の経路を特定し、各ルートの認証状態を判断し、認証バイパス/権限昇格/IDOR のリスクを検出します。

CRITICAL：完全な分析（必須）

• php-route-mapper に出現するすべてのルートを処理する必要があります。
• 認証チェーン（Session/JWT/ミドルウェア/カスタム検証関数）を特定する必要があります。
• ルートと認証のマッピングテーブルを出力する必要があります（省略なし）。
• すべての疑わしい点について、以下の情報を提供する必要があります：位置の証拠 + データフローチェーン + 悪用可能性分析 + 検証 PoC + 修正提案。

実行モード（必須：パイプラインフェーズと整合）

このスキルは、"trace が生成される前に EVID_* を参照できない"という問題を解決するために、2つのモードをサポートしています。

1. STATIC_MAPPING（パイプラインフェーズ 1 で推奨）

   • auth_mapping_{timestamp}.md のみを生成します（およびオプションで auth_README_{timestamp}.md）。
   • php-route-tracer の EVID_* 証拠点参照が欠落していても構いません。
   • 認証状態の分類（✅/⚠️/❌/❓）と P0/P1 バケットの根拠（PoC は不要）を提供する必要があります。

2. TRACE_AUDIT（パイプラインフェーズ 4 で推奨、trace が既に存在する場合）

   • 完全な auth_audit_report_{timestamp}.md を生成し、trace 契約の EVID_* 証拠点を強制的に個別に参照します。
   • PoC/修正提案はすべて揃っている必要があります。

脆弱性分類

詳細は shared/SEVERITY_RATING.md を参照してください。

入力依存

推奨される入力（shared/IO_PATH_CONVENTION.md と一致；パイプラインを統合する際は、総レポートの同等セクションを読み込みます）：

• routes_{timestamp}.md（独立してディスクに保存される場合は通常 route_mapping/routes_{timestamp}.md）
• params_{timestamp}.md（独立してディスクに保存される場合は通常 route_mapping/params_{timestamp}.md）

オプション：

• source_path

認証実装の特定（必須）

フレームワークごとに特定します：

• Laravel：
  • middleware('auth'|'can'|'role:')
  • Auth::check()/Auth::user()
  • Policies/Gates：Gate::allows、->can({value})
  • ルート保護：Route::middleware([{value}])->group({value})
• Symfony：
  • security.yaml / access_control
  • denyAccessUnlessGranted、isGranted
  • voter/policy
• ネイティブ PHP：
  • session_start + $_SESSION 判断
  • if (!isset($_SESSION['user']))/requireLogin()
  • カスタム関数：checkAuth/authorize/hasRole/isAdmin

ルートと認証のマッピング（必須）

各ルートについて、以下の状態を出力します：

• ✅ 公開：明示的に許可されており、認証チェックなし
• ✅ 保護済み：完全な認証/認可チェックが存在
• ⚠️ 認証のみ：ログイン状態のみを検証し、ロール/リソースレベルの認可なし
• ❌ 認証なし：認証経路が一切ヒットしない
• ❓ 不明：動的な権限/複雑なカスタムロジックにより判断が困難（それでも証拠点を記述する必要があります）

また、リスクタイプとして AUTH を出力します。これには以下が含まれます：

• 認証バイパス（ログイン状態の検証がバイパスされる）
• 認可バイパス/権限昇格（ロール検証の欠落または誤り）
• IDOR（オブジェクトアクセスにおける所有権/帰属検証の欠落）

疑わしいパターンの検出（必須、証拠チェーンを提供）

1) パス/URI の不一致による認証バイパス

PHP での一般的な根本原因：

• 元の $_SERVER['REQUEST_URI'] または parse_url の結果を使用してホワイトリストマッチングを行うが、パスが正規化されていない
• エンコーディング/大文字小文字/重複スラッシュ/末尾文字の違いによりマッチングが失敗する（実際のルートは保護されたハンドラに入る）

出力必須：

• ホワイトリストチェックの位置とコードスニペット
• バイパスリクエスト（PoC）とヒットしたハンドラの証拠

2) ログイン状態のみを検証し、ロール/リソース認可が欠落している

出力必須：

• ルートの「認証チェック」位置
• 「認可チェックの欠落」位置（例：user!=null の判断後に直接機密操作を実行する場合）

3) IDOR/権限昇格

出力必須：

• 機密オブジェクト ID の取得元（GET/POST/URL）
• クエリ/更新に使用される「帰属検証」の有無（WHERE 句に user_id/owner_id が含まれているか）
• 未検証の理由と到達可能性

レポート出力（実行モード別）

出力先：

{output_path}/auth_audit/
├── auth_audit_report_{timestamp}.md
├── auth_mapping_{timestamp}.md
└── auth_README_{timestamp}.md

強制ルール：

• STATIC_MAPPING：auth_mapping_{timestamp}.md を生成する必要があります。auth_audit_report_{timestamp}.md は省略するか、空のシェルを生成できます（その場合、「バケットマッピングのみ、trace 証拠なし」と明記します）。
• TRACE_AUDIT：完全な3つのファイルを生成する必要があり、trace 証拠点がすべて揃っている必要があります。

ファイル1：メインレポート auth_audit_report_{timestamp}.md

内容：

• 認証フレームワークの特定（バージョン/実装の証拠を含む）
• 認証アーキテクチャの概要（ミドルウェア/関数/ハンドラ）
• リスク統計
• 各リスクの完全な脆弱性構造（番号/分類/データフロー/PoC/修正）

ファイル2：マッピングテーブル auth_mapping_{timestamp}.md

ルートと認証状態、必要なロール/条件のみをリストします（脆弱性の詳細な分析は含めません）。 ただし、バケットフィールドを新たに追加する必要があります（パイプラインフェーズ 3 でのルーティング選択用）：

• p_bucket：P0 または P1
  • P0：❌ 認証なし
  • P1：⚠️ 認証のみ、または認証バイパス/権限昇格/IDOR リスクが検出された場合（認証状態が「認証のみ」と表示されていても、p1_reason で P1 に分類された理由を説明する必要があります）
• p1_reason：短い静的根拠（例：「ログイン状態のみ、hasRole/authorize が欠落しているか、owner_id 検証が欠落している」）

ファイル3：説明ドキュメント auth_README_{timestamp}.md

方法論、ツール、検証ガイドラインのみを説明し、具体的な脆弱性の詳細は含みません。

PoC 検証テンプレート（必須）

少なくとも以下のシナリオを区別する必要があります：

• 未ログインアクセス（cookie/session/JWT なし）
• 一般ユーザーアクセス（一般アカウントの cookie/JWT）
• 管理者/高権限との比較（該当する場合）

PoC は実行可能な HTTP リクエストコードブロックである必要があり、ルートパスは実際のルーティングルールを使用する必要があります。

証拠参照（実行モード別必須）

• STATIC_MAPPING：trace の EVID_* 証拠点の参照は強制されません（認証分類と P0/P1 バケットの根拠のみを出力します）。
• TRACE_AUDIT：各認証リスクの疑いについて、trace 出力からの証拠を個別に参照する必要があります（状態を「検証待ち」とマークすることは許可されますが、証拠参照は存在する必要があります）：

1. EVID_AUTH_PATH_PROTECTED_MATCH：ルートが保護されたハンドラに入るパスマッチングの証拠（trace の分岐パス証拠に対応）
2. EVID_AUTH_TOKEN_DECODE_JUDGMENT：ログイン状態/トークンデコード結果がどのように判断されたかの証拠（trace の session/JWT 読み取りと条件分岐に対応）
3. EVID_AUTH_PERMISSION_CHECK_EXEC：権限判断関数または条件文（例：hasRole/authorize）の実行証拠（trace シンク特定または分岐証拠）
4. EVID_AUTH_IDOR_OWNERSHIP_CONDITION：IDOR 帰属検証（WHERE/条件）に owner_id/user_id が含まれているかの証拠（trace の最終クエリ条件または状態更新文）

tracer 証拠欠落の処理（必須）

• STATIC_MAPPING：適用されません（バケットの根拠は静的コードの証拠に基づきます）。
• TRACE_AUDIT：trace 契約の検証が失敗した場合、または 1～4 のいずれかの重要な証拠点を特定できない場合：そのリスクは ⚠️検証待ち とマークされるだけであり、✅悪用可能と確認済み または「バイパス可能と確定」という結論を出すことはできません。