PHP CRLF 応答分割監査（php-crlf-audit）

PHP プロジェクトのソースコードを分析し、ユーザーが制御可能なデータが応答ヘッダー（header）、Cookie、またはブラウザ/ミドルウェアによって新しいヘッダーとして解釈される可能性のある他の場所に入り込み、応答分割、キャッシュポイズニング、またはリダイレクトハイジャックを引き起こすかどうかを識別します。

分類と番号付け

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

必須検査シンク（強制）

以下の点を識別してください。

• header() のヘッダー値パラメータにユーザー入力が含まれている場合
• setcookie() の cookie name/value/domain/path にユーザー入力が含まれている場合
• カスタムヘッダーに出力する関数/ラッパー（最終的には header を呼び出すもの）
• HTTP 応答ヘッダーに連結されてボディ内に出力されるもの（まれですが、コード内で証拠化する必要があります）

必須検査フィルターと正規化（強制）

以下を必ず出力してください。

• \r、\n に対して拒否またはサニタイズが行われているか
• 可視制御文字に対して処理が行われているか
• URL エンコード/エスケープが行われているか（ただし、注意：誤った「部分的なフィルタリング」は回避される可能性があります）

PoC（強制）

• 実際のルートと制御可能なフィールド名を必ず提示してください。
• ペイロードは CRLF を示す必要があります：%0d%0a（または \r\n）と、期待される効果（Location またはカスタムヘッダーの注入など）を説明してください。

レポート出力

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

項目テンプレート（強制）

必ず以下を含めてください：位置の証拠 + データフローチェーン + 悪用可能な前提条件 + PoC + 修正提案 + コード検索ステートメント。

証拠引用（強制：php-route-tracer から）

各 CRLF/応答分割の疑わしい脆弱性について、trace 出力中の ## 9) Sink Evidence Type Checklist の CRLF 行に対応する証拠要点（状態は未検証でも構いませんが、証拠引用は必須です）を個別に引用する必要があります。

1. EVID_CRLF_OUTPUT_POINT：応答ヘッダー/Cookie 出力点の位置の証拠（header/setcookie などの最終出力位置）
2. EVID_CRLF_USER_INPUT_INTO_HEADER_COOKIE：ユーザー入力が header/cookie 値に入り込む証拠（制御文字の入り込み点を含む）
3. EVID_CRLF_CONTROL_CHAR_FILTERING_ENCODING：\r\n または制御文字のフィルタリング/エンコードの証拠（拒否/サニタイズ/エンコードの実装に対応する部分）

tracer 証拠欠落処理（強制）

• 上記 1～3 のいずれかの重要な証拠要点が見つからない場合：その脆弱性の状態は ⚠️未検証 とマークするしかなく、直接 ✅悪用可能と確認済み を与えることはできません。