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 のみで記録され、アラートチャネルに送られない
• ログレベルやアラートルールの欠落（例：production でセキュリティアラート用 channel が無効になっている）
• 例外の処理で例外が握りつぶされ、重要なイベントが記録されない

出力要件：

• ソースコードで特定したログレベル／チャネル／handler 設定の証拠
• それらの証拠が、アラートのトリガーや重要な証拠の取得をどのように妨げるか

特定ロジック（必須）

ログ書き込み先（コード）

以下のログ関連 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}、またはプロジェクト独自の logger wrapper
• Monolog：Monolog\Logger および handler／channel 関連の設定

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

ログ書き込み箇所ごとに、少なくとも1つの経路を追跡する必要があります：

• Source（リクエストフィールド／ユーザー入力／機密トークンの出所） -> 中間変数での処理（連結、フォーマット、json_encode、テンプレート文字列） -> Sink（最終的にログへ書き込まれる message 引数）

以下を出力します：

• 制御可能なフィールド名（または JSON パス）
• ログに渡される前にサニタイズされているか（改行／制御文字／機密フィールドのマスキング）
• 条件分岐によって「特定の分岐でしかログが記録されない」など、ログが回避される可能性があるか

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

「ログの不備」はログ出力の確認が必要になることが多いため、可観測性のある PoC フレームワークを提示する必要があります（実行可能、または手動で検証可能）。少なくとも以下のいずれかを含めてください：

• 実際のルートを使ってログ記録を発生させ、ログに現れるフィールド／形式の変化を説明する
• 改行／制御文字を含むペイロードを構成し、ログ行が分割される、または偽の断片が現れることを説明する

PoC の出力要件：

• 実際のルートを必ず含める（優先して routes_{timestamp}.md から置き換える。個別に保存する場合は route_mapping/routes_{timestamp}.md を参照。規約は shared/IO_PATH_CONVENTION.md を参照）
• トリガーに使用するリクエストヘッダーと body／パラメーターを明記する（ログメッセージに入る制御可能なフィールドを少なくとも1つ含める）
• ログファイル／コンソール／システムログで確認する内容を明記する（例：あるフィールドがそのまま出現するか）

レポート出力

出力先：

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

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

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

### [{等级前缀}-LOG-{序号}] {风险标题}

| 项目 | 信息 |
|------|------|
| 严重等级 | {🔴/🟠/🟡/🔵} (CVSS {score}) |
| 可达性 (R) | {0-3} - {理由} |
| 影响范围 (I) | {0-3} - {理由} |
| 利用复杂度 (C) | {0-3} - {理由} |
| 可利用性 | ✅ 已确认 / ⚠️ 待验证 / ❌ 不可利用 / 🔍 环境依赖 |
| 位置 | {file}:{line} ({Function/Class}) |

#### 漏洞类型与证据点
- 缺陷类别：{Audit Gap / Sensitive Data in Logs / Log Injection / Monitoring Gap}
- 证据点 A（日志写入调用点）：{file}:{line} 说明
- 证据点 B（消息构造/可控字段进入点）：{file}:{line} 说明
- 证据点 C（净化/脱敏是否存在）：{file}:{line} 说明（如无则写“未发现脱敏/未发现过滤”并给出搜索结论）

#### 数据流链（Source -> Transform -> Sink）
（逐行写出：请求输入如何被读取/解析/格式化 -> 是否进入日志 message -> 最终写入日志）

#### 可利用前置条件
- 鉴权要求：{无需/需登录/需特定权限}
- 输入可控性：{完全可控/条件可控/不可控}
- 触发条件：{分支/错误路径/异常路径/日志级别条件}
- 可观测性：{日志落地位置是否可读/是否在生产可见/是否需要运维权限}

#### 验证 PoC（强制，可观测）
```http
{HTTP Method} {真实路由与完整参数} HTTP/1.1
Host: {host}
{必要 Header/Session/JWT/Cookie}

{Payload}

（PoC の後に確認するログ上の現象：予想されるログ内容／形式の変化／改行による分割の有無を明確に記載）

修正案

• 安全な実装の要点：機密フィールドのマスキング、制御文字のサニタイズ、構造化ログ、ログレベルとアラートの対応付け
• コード検索コマンド：rg を使って、すべてのログ書き込み箇所とメッセージ構築に関係するコードブロックを特定する

## 输出完整性检查（强制）
- [ ] 每条漏洞都包含：编号、等级、位置、数据流链、可利用前置条件、可观测 PoC、修复建议
- [ ] 日志注入类问题必须明确使用控制字符 payload（至少包含换行注入场景）
- [ ] 敏感信息类问题必须明确指出敏感字段来源与写入位置
- [ ] 审计缺失类问题必须明确指出“应该记录但未记录”的对照逻辑（基于源码事件点推断，而不是泛泛而谈）