PHP ファイルシステム操作監査（php-filesystem-audit）

PHP プロジェクトにおけるファイルシステムへの重要な操作を分析し、特に以下の点とどのように連携しているかに焦点を当てます。

• パス検証/正規化の失敗（ディレクトリトラバーサル、basePath の欠落）
• 書き込み/読み取り/インクルードの着地点チェーン
• 書き込み後のトリガー（実行可能性、インクルード可能性）
• 競合状態（TOCTOU）

これらの連携により、実際の悪用可能性を高めます。

適用範囲（必須）

以下の点について、「証拠点 + リスク説明 + 悪用可能性判断」を網羅し、出力する必要があります。

1) 作成/ディレクトリ操作

• mkdir($path, $mode, $recursive)
• rmdir($path)
• touch($path)
• tmpfile() / tempnam()
• フレームワークがカプセル化したディレクトリ作成（例: Storage::put/ensureDirectory の基盤となるカプセル化、識別可能な場合）

2) 権限/所有権の変更（権限昇格チェーンや実行ポリシーの回避によく使用されます）

• chmod/chown/chgrp
• umask

3) リンクとリダイレクトの着地点（一般的な symlink/hardlink 回避）

• symlink($target, $link)
• link($target, $link)
• readlink($path)

4) 削除とクリーンアップ（TOCTOU または上書きチェーンと組み合わせる）

• unlink($path)
• unlink/rename の変種による削除
• rename($src, $dest)（着地点変更時に TOCTOU に特に注意が必要）
• copy/move の変種（「着地点準備ステップ」として出現する場合）

5) パス競合と TOCTOU（個別に監査必須）

「チェック-使用分離」のコードパターンについて判定します。

• if (realpath/canonicalize + プレフィックス検証) の後、何らかの分岐/例外処理で再度 join/open/write が行われているか（パスが変化する可能性）
• 最初に書き込み可能かを判断してから書き込む、最初にチェックしてからファイル操作を実行するパターンが存在するか
• シンボリックリンクの解決/不整合な解決が存在するか（チェック時と実際に開く時の解決済みパスが一致しない）

主要な出力要件（必須）

各発見には以下を含める必要があります。

1. 位置の証拠：ファイルパスと関数/呼び出し点（可能な限り行番号を記載。行番号が見つからない場合は特定が必要とマーク）

2. 操作タイプ：作成/権限/リンク/削除/名前変更/コピーなど

3. パス制御のソース：パスパラメータが GET/POST/SESSION/設定、またはハードコードされているか

4. チェーンとの関係（少なくとも1つ選択して説明必須）：

   • WRITE/UPLOAD の着地点の実行可能性またはインクルード可能性との関連
   • FILE（読み取り/インクルード）または ARCHIVE（解凍着地点）との関連
   • 認証/リソース所有権との関連（例：管理者ディレクトリのみ書き込み権限があるが回避されている）
   • TOCTOU 競合との関連（チェック点 -> 使用点の間でパスが置き換えられる可能性）

5. 悪用可能性判断：

   • ✅ 確認済み：このファイルシステム操作が、悪用チェーンの主要な前提条件を提供すること（または WRITE/UPLOAD/FILE の証拠と閉ループを形成すること）を証明できる。
   • ⚠️ 検証待ち：リスクは存在するが、主要な前提条件が欠けているか、トレース/解析の証拠が不十分。
   • ❌ 悪用不可：強力な制約がある（baseDir の許可リストが有効、解決済みパスの一貫性保護、権限が固定されており変更不可、競合ウィンドウが解消されている）。
   • 🔍 環境依存：特定のファイルシステム/権限/並行処理のタイミング/サーバー側のディレクトリ構造に依存する。

6. トリガー可能性の制約（必須）：

   • 「具体的な HTTP ルート/エントリポイントによってトリガーされ得る」ファイルシステム操作のみを脆弱性項目として生成し、PoC に使用できる実際のルートと完全なパラメータを提供できる必要があります。
   • 具体的なルートエントリポイントを特定できない場合（純粋なバックグラウンドタスク/定期タスク/コマンドラインツールでエントリポイントが追跡できない場合など）、その FS リスクはレポートに「エントリポイントを特定できなかったため、項目生成をスキップします（手動でトリガーパスを補完する必要があります）」とマークするのみとし、実行不可能な PoC を脆弱性項目テンプレートに強制的に出力してはなりません。

レポート出力

以下に出力します。

{output_path}/vuln_audit/fs_{timestamp}.md

脆弱性番号の規則（推奨：FS）

• 詳細については、shared/SEVERITY_RATING.md を参照してください。
• 脆弱性番号：{C/H/M/L}-FS-{連番}

脆弱性項目テンプレート（必須）

各発見は以下の構造に従う必要があります（省略不可）。

### [{等級プレフィックス}-FS-{連番}] ファイルシステム操作チェーンリスク（権限/リンク/削除/TOCTOU/パス制御）

| 項目 | 情報 |
|------|------|
| 深刻度 | {🔴/🟠/🟡/🔵} (CVSS {score}) |
| 到達可能性 (R) | {0-3} - {理由} |
| 影響範囲 (I) | {0-3} - {理由} |
| 悪用複雑度 (C) | {0-3} - {理由} |
| 悪用可能性 | ✅ 確認済み / ⚠️ 検証待ち / ❌ 悪用不可 / 🔍 環境依存 |
| 位置 | {file}:{line} ({Function/Class}) |

#### データフローチェーン（Source → Path Control → FS Operation → Chain Influence）
（ユーザー/コンテキスト入力がどのようにパス制御変数に入り、realpath/canonicalize およびプレフィックス検証を経由したか、最終的に mkdir/chown/symlink/unlink/rename/などのファイルシステム操作パラメータにどのように到達したか、そしてそのファイルシステム操作が後続のチェーン能力（WRITE/UPLOAD/FILE/ARCHIVE/CMD/TPL/EXPR/DESER など）にどのように影響するかを一行ずつ記述します）

#### 悪用可能な前提条件
- 認証要件：{不要/ログイン必要/特定の権限必要}
- 入力制御性：{完全に制御可能/条件付きで制御可能/制御不可}
- トリガー条件：{分岐/例外パス/特定のファイルシステム権限が必要/競合ウィンドウが必要/特定のディレクトリ構造が必要}
- チェーンの引き継ぎ：{他のシンクカテゴリに「悪用可能性の向上」をどのように提供するか（書き込み着地点/インクルード可能性/権限昇格/実行ポリシーの回避/競合のトリガー）}

#### 検証 PoC（必須：観測可能な検証フレームワーク）
```http
{HTTP Method} {実際のルートと完全なパラメータ} HTTP/1.1
Host: {host}
{必要な Header/Session/JWT/Cookie}

{Payload}

PoC 出力/観測点（明確に記述必須）：

1. この FS 操作によって引き起こされるファイルシステムの状態変化が観測可能か（例：ターゲットパス下のファイル作成/権限変化/リンクの指す先の変化/削除結果/最終的な着地点の存在）。
2. TOCTOU の場合：「チェック点と使用点の解決済みパスの不一致/ウィンドウが悪用可能である」という観測可能な現象を示す（例：並行トリガーによる最終的な着地点の変化）。

証拠引用（必須：ソースコードスニペットから）

位置に対応する証拠スニペットを少なくとも3つ含める必要があります（重要な行をテキストで直接繰り返すこともできます）。

1. FS 操作の呼び出し点（mkdir/chmod/chown/symlink/unlink/rename など）およびパラメータの位置（file:line）
2. パス検証/正規化ロジック（realpath/canonicalize/baseDir プレフィックス検証）および FS 操作との関係（同一関数内または関数間）
3. パス制御のソース（GET/POST/SESSION/設定のハードコードなど）およびその伝達チェーン

推奨される修正

• パス検証と実際の使用は、同じ解決済みターゲットにバインドする必要があります：realpath/canonicalize の後、同じ値を使用して open/rename/write を行います（TOCTOU を回避するため）。
• 攻撃者によって影響され得るパスに対して、「最初に検証してから使用する」という分割を禁止します。分割が必須の場合、同じシステムコール/同じファイル記述子コンテキスト内で完了する必要があります。
• symlink/hardlink については、ターゲットの着地点でリンク防止ポリシーを有効にします（プラットフォームがサポートしている場合はシンボリックリンクの追跡を無効にするか、inode/ファイル記述子に基づいて一貫性を検証します）。
• 権限変更は最小限に抑え、ユーザーが影響できないようにする必要があります。攻撃者が chmod/chown のパスを制御できないようにします。

コード検索クエリ（必須）

rg -n "(mkdir\\(|rmdir\\(|touch\\(|tmpfile\\(|tempnam\\(|chmod\\(|chown\\(|chgrp\\(|symlink\\(|readlink\\(|link\\(|unlink\\(|rename\\(|copy\\(|symlink\\()" .
rg -n "(realpath\\(|canonicalize\\(|dirname\\(|basename\\(|baseDir|dest(path)?|target(path)?)" .

修正提案（必須要点）

• パス検証と実際の使用は、同じ解決済みターゲットにバインドする必要があります：realpath/canonicalize の後、同じ値を使用して open/rename/write を行います（TOCTOU を回避するため）。
• 攻撃者によって影響され得るパスに対して、「最初に検証してから使用する」という分割を禁止します。分割が必須の場合、同じシステムコール/同じファイル記述子コンテキスト内で完了する必要があります。
• symlink/hardlink については、ターゲットの着地点でリンク防止ポリシーを有効にします（プラットフォームがサポートしている場合はシンボリックリンクの追跡を無効にするか、inode/ファイル記述子に基づいて一貫性を検証します）。
• 権限変更は最小限に抑え、ユーザーが影響できないようにする必要があります。攻撃者が chmod/chown のパスを制御できないようにします。