[スキル名] php-logging-audit

PHP セキュリティログと監視の監査（php-logging-audit）

PHP プロジェクトにおける「セキュリティの可観測性」に関するコードと設定の欠陥を分析します。主な目的は「ログを記録すべきか否か」を一般化することではなく、具体的な問題を特定することです。例えば、攻撃者が入力によってログを汚染できるか、システムが機密情報をログに書き込んでいるか、重要なセキュリティイベントが欠落しているか、そしてアラート/監査チェーンが破壊されているか、といった点です。

分類と番号付け

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

適用範囲（必須：各項目をチェックし、証拠を出力すること）

このスキルは、以下の4種類の欠陥をカバーし、それぞれについて「証拠点 + 影響 + 悪用可能性分析 + 修正推奨事項」を提供する必要があります。

1) セキュリティイベント監査の欠落（Audit Gap）

欠落しているセキュリティイベントのログポイントを特定します。例えば（プロジェクトの実際の入口に基づきます）：

• ログイン失敗/成功とアカウント列挙に関連する失敗原因の記録（機密情報の漏洩を避けるため）
• 権限拒否/権限昇格の試行（拒否原因は抽象化して記録可能）
• パスワードリセット、メールアドレス変更、管理者ロール変更、2FA変更などの重要なアカウントイベント
• 機密性の高い操作（データのエクスポート、キーのダウンロード、権限の削除/変更、一括インポート）
• CSRF検証失敗、セッション失効、ログアウト成功などのセキュリティ関連の状態変化

出力要件：

• 「どのようなイベントを記録すべきか」（ソースコードで特定した機能点にマッピングして）
• 「実際にログが書き込まれる場所が存在するか/迂回されているか」（証拠を提示）
• 欠落によって生じる現実的な結果の推論（例：監査が利用できない、事後追跡が不可能、アラートがトリガーされない）

2) ログへの機密情報書き込み（Sensitive Data in Logs）

機密データをログに書き込む可能性のあるすべてのパスを特定します。

• Authorization ヘッダー、Cookie、session_id、JWT の原文
• パスワード/検証コード/リカバリートークン/ワンタイムパスワード
• ユーザーのプライバシーデータが失敗スタックやデバッグ出力でそのまま出力される
• リクエストボディ/パラメーター（特にキーフィールドを含むもの）をログメッセージに直接連結する

出力要件：

• 機密情報のソース（どの変数/リクエストフィールドから来るか）
• ログ書き込みの呼び出し点とメッセージの構築方法
• ログの保存媒体（ファイルパス/システムログチャネル/ログライブラリ）

3) ログインジェクションと偽造（Log Injection / Forging）

「ユーザーが制御可能な文字列がログメッセージに入力されるが、制御文字のサニタイズが行われていない」問題を特定します。

• \r / \n がログメッセージに入り、ログ行が分割される
• タイムスタンプ、レベル、リクエストパスなどの「偽の項目」が偽造される可能性がある
• ログ形式が JSON またはキーバリューペアを使用している場合、エスケープの欠陥によって構造が破壊される可能性がないか確認する

出力要件：

• どのフィールドが制御可能か（GET/POST/Headers/Body/Cookie）
• インジェクションの入り口（ログメッセージの連結点）
• フィルタリング/正規化が存在するか（特に改行と制御文字の処理）

4) ログとアラートチェーンの欠陥（Monitoring & Alert Gaps）

監視チェーンのギャップを特定します（コード/設定で証明できるものに限る）。

• 重要なセキュリティイベントが debug/info レベルでしか記録されず、アラート可能なチャネルに入っていない
• ログレベルとアラートルールの欠落（例：本番環境でセキュリティアラートチャネルがオフになっている）
• エラー処理が例外を飲み込み、重要なイベントが書き込まれない

出力要件：

• ソースコードで特定したログレベル/チャネル/ハンドラー設定の証拠
• これらの証拠がどのようにアラートのトリガー不能や重要な証拠の取得不能につながるか

識別ロジック（必須）

ログ書き込みシンク（コード）

以下のログ関連 API を特定する必要があります（プロジェクトの実際のものに置き換えてください）：

• PHP：error_log({value})
• システム：syslog({value})
• PSR-3/フレームワーク：->info({value}) ->warning({value}) ->error({value}) ->critical({value}) ->debug({value})
• Laravel/Symfony/カスタムラッパー：Log::{value}({value})、logger->{value} またはプロジェクト独自のロガーラッパー
• Monolog：Monolog\Logger およびハンドラー/チャネル関連の設定

メッセージ構築と制御可能性（データフロー）

各ログ書き込み点について、少なくとも1つのチェーンを追跡する必要があります。

• ソース（リクエストフィールド/ユーザー入力/機密トークンのソース） -> 中間変数処理（連結、フォーマット、json_encode、テンプレート文字列） -> シンク（最終的にログに書き込まれるメッセージパラメーター）

そして、以下を出力します。

• 制御可能なフィールド名（または JSON パス）
• ログに入る前にサニタイズが行われているか（改行/制御文字/機密フィールドの匿名化）
• 「特定のブランチのみログを書き込む」という条件分岐があるか（ログ書き込みの迂回）

PoC（必須：可観測検証フレームワーク）

「ログの欠陥」はログ出力を観察する必要があるため、可観測な PoC フレームワーク（実行可能または手動で検証可能）を提供する必要があります。少なくとも以下の2種類のいずれかを含めてください。

• 実際のルートを使用してログ書き込みをトリガーし、ログに表示されるフィールド/形式の期待される変化を説明する
• 構築されたペイロードを使用して改行/制御文字を注入し、ログが分割されるか、偽造された断片が出現するかの期待される結果を説明する

PoC 出力要件：

• 実際のルートを含める必要があります（routes_{timestamp}.md から優先的に置き換える。独立したファイルは route_mapping/routes_{timestamp}.md を参照。規約は shared/IO_PATH_CONVENTION.md を参照）。
• トリガーに使用するリクエストヘッダーとボディ/パラメーターを記述する必要があります（少なくともログメッセージに入る制御可能なフィールドを1つ含む）。
• ログファイル/コンソール/システムログで何を観察すべきかを明確に説明する必要があります（例：特定のフィールドがそのまま表示されるか）。

レポート出力

出力先：

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

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

各脆弱性は以下の構造に従う必要があります（省略不可）：

### [{等級プレフィックス}-LOG-{連番}] {リスクタイトル}

| 項目 | 情報 |
|------|------|
| 深刻度 | {🔴/🟠/🟡/🔵} (CVSS {スコア}) |
| 可達性 (R) | {0-3} - {理由} |
| 影響範囲 (I) | {0-3} - {理由} |
| 利用複雑度 (C) | {0-3} - {理由} |
| 悪用可能性 | ✅ 確認済み / ⚠️ 検証待ち / ❌ 悪用不可 / 🔍 環境依存 |
| 位置 | {ファイル}:{行} ({関数/クラス}) |

#### 脆弱性タイプと証拠点
- 欠陥カテゴリ：{Audit Gap / Sensitive Data in Logs / Log Injection / Monitoring Gap}
- 証拠点 A（ログ書き込み呼び出し点）：{ファイル}:{行} 説明
- 証拠点 B（メッセージ構築/制御可能フィールドの入り口）：{ファイル}:{行} 説明
- 証拠点 C（サニタイズ/匿名化の有無）：{ファイル}:{行} 説明（ない場合は「匿名化未発見/フィルタリング未発見」と記述し、検索結果を提示）

#### データフローチェーン（Source -> Transform -> Sink）
（一行ずつ記述：リクエスト入力がどのように読み取られ/解析され/フォーマットされるか -> ログメッセージに入るか -> 最終的にログに書き込まれるか）

#### 悪用可能な前提条件
- 認証要件：{不要/ログイン必要/特定権限必要}
- 入力制御可能性：{完全に制御可能/条件付きで制御可能/制御不可}
- トリガー条件：{分岐/エラーパス/例外パス/ログレベル条件}
- 可観測性：{ログの保存場所が読み取り可能か/本番環境で可視か/運用権限が必要か}

#### 検証 PoC（必須、可観測）
```http
{HTTP メソッド} {実際のルートと完全なパラメーター} HTTP/1.1
Host: {ホスト}
{必要なヘッダー/セッション/JWT/Cookie}

{ペイロード}

（PoC の後、観察すべきログ現象：{期待されるログ内容/形式の変化/改行による分割の有無を明確に記述}）

推奨される修正

• 安全な記述の要点：機密フィールドの匿名化、制御文字のサニタイズ、構造化ロギング、ログレベルとアラートのマッピング
• コード検索クエリ：rg を使用して、すべてのログ書き込みとメッセージ構築に関連するコードブロックを特定する

出力完全性チェック（必須）

• [ ] 各脆弱性には、番号、等級、位置、データフローチェーン、悪用可能な前提条件、可観測 PoC、修正推奨事項が含まれていること
• [ ] ログインジェクションタイプの問題では、制御文字ペイロード（少なくとも改行インジェクションのシナリオを含む）を明確に使用すること
• [ ] 機密情報タイプの問題では、機密フィールドのソースと書き込み位置を明確に指摘すること
• [ ] 監査欠落タイプの問題では、「記録すべきだが記録されていない」という対照ロジックを明確に指摘すること（ソースコードのイベント点に基づいて推論し、一般的な議論ではないこと）