[Skill 名] php-symfony-audit

PHP Symfony フレームワークセキュリティ監査（php-symfony-audit）

Symfony プロジェクトのソースコードにおける「フレームワーク固有のセキュリティメカニズム」と「設定/使用上の落とし穴」を分析し、以下の点を重点的にカバーします。

• config/packages/security*.yaml の access_control、firewalls 設定の正確性
• CSRF 防御メカニズム（フォーム送信とトークン検証）
• Twig レンダリングの自動エスケープと raw 出力のリスク
• Symfony アクセス式とセキュリティインターセプトチェーン（状況に応じて AUTH/EXPR/TPL にマッピング）
• HttpClient の外部連携戦略（SSRF 関連のリスクは一般的な SSRF タイプにマッピング）

入力

ユーザーが提供するもの：

• source_path：Symfony プロジェクトのソースコードのルートディレクトリ オプション：
• output_path：出力ディレクトリのパス（デフォルトは {source_path}_audit）

出力ディレクトリ

以下に出力されます。

{output_path}/framework_audit/
  symfony_{timestamp}.md

フレームワーク識別（必須）

Symfony であると識別された証拠点を提示する必要があります（根拠のない断言は許可されません）。

• 典型的なディレクトリ：config/、src/、templates/
• 依存関係の証拠：composer.json 内の symfony/framework-bundle など
• エントリポイントの証拠：public/index.php または類似のフロントコントローラー

リスクタイプマッピング（必須）

すべての発見について、以下を明記する必要があります。

• 適用される汎用タイプコード：AUTH / CSRF / CFG / XSS / TPL / LOGIC / SESS / SSRF / EXPR など
• マッピング理由：なぜその Symfony リスクがそのタイプコードに該当するのか（一文で）

必須監査リスト（必須：各項目をチェックし、結果を出力）

1) アクセス制御と認証ポリシー（AUTH）

以下を特定し、出力する必要があります。

• security.yaml 内の access_control ルール
• firewalls 設定（anonymous: true かどうか、stateless: true かどうか、および認証方法）
• switch_user、role_hierarchy または voter/policy 関連の設定（存在する場合）

判定ルール：

• 広すぎる許可（例：機密パスをカバーする汎用的な匿名ルール）が存在する場合、AUTH リスクを出力します。
• 「認証はあるがロール/所属の検証が不足している」パターンが存在する場合、AUTH または LOGIC リスクを出力します。

2) CSRF 防御（CSRF）

以下を特定し、出力する必要があります。

• Symfony CSRF 関連の設定（framework: csrf_protection またはコンポーネントレベルの設定）
• フォームタイプ使用における CSRF token の生成と受信方法
• token 検証失敗時の処理パス（早期終了するか、特定ブランチでのみ検証するか）

判定ルール：

• 「特定のルート/フォームで CSRF が無効になっている、または CSRF token 受信フィールドが一致しない」場合、CSRF リスクを出力します。

3) Twig 自動エスケープと raw 出力（XSS/TPL）

以下を特定し、出力する必要があります。

• Twig 設定：自動エスケープが無効になっているかどうか（グローバルまたはローカル）
• テンプレート内の raw 出力点：|raw、{% autoescape false %}、および「エスケープを回避する」すべてのディレクティブ
• データソース：raw 出力される変数がどこから来ているか（request/session/データベースフィールド）

判定ルール：

• raw 出力される変数のソースが制御可能であり、エスケープされていない場合、XSS または TPL にマッピングします（式実行/テンプレートエンジンが制御可能な場合）。

4) セキュリティ式と評価リスク（EXPR/TPL/AUTH）

以下を特定し、出力する必要があります。

• ExpressionLanguage が security で使用されている場所（voter/policy 内の is_granted または式条件）
• 式文字列のソースがユーザーによって制御される可能性があるかどうか（例：式連結）

判定ルール：

• 式文字列が制御可能な場合、EXPR または TPL リスクとして出力します。

5) 外部 HTTP 接続と内部ネットワークアクセス（SSRF）

以下を特定し、出力する必要があります（フレームワーク関連のチェックのみ）。

• HttpClient/KernelInterface などの外部呼び出しのラッパーエントリポイント
• URL/ホストがユーザー入力に由来するかどうか、許可リストまたは内部ネットワークインターセプトが存在するかどうか

観測可能な PoC（必須：フレームワーク固有の観測可能な検証フレームワーク）

以下のいずれか少なくとも2つを提示し、観測点を明確に記述する必要があります。

• アクセス制御エラー：未ログイン/低権限ユーザーで保護されていると思われるルートにアクセスし、応答の違いを観察します。
• CSRF エラー：CSRF token が欠落している、または偽造されたフォームリクエストを構築し、ステータスコード/エラーパスを観察します。

PoC 出力要件：

• 実際のルートと実際のフォームアクション（またはルートパス）を含める必要があります。
• 期待される観測点（例：403 が返されるか、状態変更が続行されるか）を説明する必要があります。

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

• [ ] 出力に Symfony 識別証拠点が含まれていること
• [ ] AUTH/CSRF/Twig(raw)/セキュリティ式/HttpClient(オプション) の5つのブロックすべてにチェック結果があること
• [ ] すべてのリスクに、マッピングタイプコード + 位置の証拠 + 観測可能な検証フレームワーク + 修正提案があること