[Skill 名] php-thinkphp-audit

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

ThinkPHP プロジェクトのソースコードにおける「フレームワーク特有のセキュリティメカニズム」と典型的な落とし穴のパターンを分析し、以下の点に重点を置きます。

• 認証/権限制御（auth モジュール、コントローラー/ミドルウェア gate）
• CSRF token メカニズムとスキップパス
• ThinkPHP テンプレートエンジンの自動エスケープと raw 出力のリスク
• ORM/Model 層の書き込み経路に起因する Mass Assignment（allowField/シナリオ検証）
• データベースネイティブ式/生 SQL 注入の入り口（汎用 SQL クラスのリスクにマッピング）
• debug/例外出力とセキュリティ設定スイッチ（CFG にマッピング）

入力

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

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

出力ディレクトリ

以下に出力されます。

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

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

ThinkPHP であることを証明する証拠点を提示する必要があります。

• 依存関係の証拠：composer.json に topthink/think-* または thinkphp/think-* 関連の依存関係が含まれていること
• エントリポイントの証拠：public/index.php または同等のフロントエンドエントリポイント
• 設定の証拠：config/ ディレクトリに ThinkPHP の設定ファイル（例：app.php、database.php、middleware.php など、プロジェクトの実情による）が存在すること
• 実行ディレクトリの証拠：runtime/ ディレクトリ構造（存在する場合）

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

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

• 汎用タイプコード：AUTH / CSRF / XSS / TPL / LOGIC / CFG / SESS / SQL など（あなたの統一タイプコードから選択）
• マッピング理由：なぜそのタイプコードに分類されるのか（マッピングロジックを1文で説明）

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

1) 認証と権限制御（AUTH）

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

• 認証エントリポイント：コントローラーミドルウェア/フィルター、基底クラス Controller/Behavior、ルーティング層権限ミドルウェア
• auth モジュールの使用：ThinkPHP の auth 関連機能（例：Auth/RBAC/ロール権限検証関数または同等のカプセル化）を使用しているか
• 権限検証のパラメータソース：リソース ID/ユーザー ID がどこから来るか（ルーティングパラメータ/リクエスト body/セッション）、および帰属検証が行われているか

判定ルール：

• 「ログイン状態のみを判断し、リソースの帰属/ロールの細分化が不足している」と判明した場合、AUTH リスクを出力します。
• 「権限検証が一部の分岐で欠落/異常後にバイパスされている」と判明した場合、AUTH または LOGIC リスクを出力します。

2) CSRF 防御（CSRF）

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

• CSRF token の有効化位置：設定項目/ミドルウェア/フォーム生成ロジック
• token の受信フィールド：body/header のどのフィールドから来るか（プロジェクトの実情による）
• token 検証ロジック：検証関数/ミドルウェアのエントリポイントと失敗処理（return/throw して状態変更を阻止するか）
• スキップルール：どのルーティング、どのリクエストメソッド、またはどのシナリオで CSRF 検証をスキップするか

判定ルール：

• スキップルールが存在するが、状態変更インターフェースをカバーしている場合 => CSRF リスク
• token 検証が失敗してもビジネスロジックが実行され続ける場合（例：例外が飲み込まれる）=> CSRF リスク

3) テンプレートエンジンのエスケープと raw 出力（XSS/TPL）

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

• テンプレート自動エスケープポリシー：テンプレート構文がデフォルトでエスケープされるか、グローバルに無効になっているか
• raw 出力/エスケープスキップ構文：例として、テンプレートに raw/|raw または同等のメカニズムが存在するか（プロジェクトの実情のテンプレートエンジンバージョンと使用法による）
• ユーザー入力がテンプレート変数に入るか：変数がどこから来るか（request/session/db）、および HTML/JS/属性コンテキストに直接連結されているか

判定ルール：

• raw 出力変数が制御可能でエスケープされていない場合 => XSS または TPL にマッピング（式/実行チェーンが関与する場合）

4) ORM 書き込み経路（LOGIC：Mass Assignment）

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

• 入力取得：request->param() / request->all() / $this->request->post() / 同等の構造全体をモデル書き込みに渡しているか
• モデル書き込み点：Model::create/save/update、$model->save($data)、一括代入動作
• 許可フィールドポリシー：allowField/field/シナリオ（scenario）または同等のホワイトリストメカニズムが設定されているか

判定ルール：

• 入力全体が書き込まれ、モデルに機密フィールドの deny/allow 制約が不足している場合 => LOGIC リスク
• 許可フィールドのホワイトリストが存在するが、高リスクフィールドが含まれている場合 => LOGIC リスク

5) データベースネイティブ式/生 SQL リスク（SQL）

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

• ネイティブ SQL エントリポイント：Db::query($sql)、Db::execute($sql)、whereRaw、orderRaw、buildExpression など（プロジェクトの実情による）
• ユーザー入力がネイティブ式に入る証拠：連結、テンプレート置換、文字列結合点
• パラメータ化/バインディングポリシーが存在するか：->bind/placeholder/prepare など（プロジェクトの実情による）

判定ルール：

• ユーザー入力が文字列連結のネイティブ SQL 式に入る場合 => SQL リスク

6) セキュリティ設定とデバッグ露出（CFG/SESS）

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

• debug/例外出力：app_debug、trace、エラーページ出力ポリシー、ログレベル（プロジェクトの実情による）
• cookie/session セキュリティパラメータ：プロジェクト設定ファイルが可視の場合（HttpOnly/Secure/SameSite など）、SESS/CFG リスクマッピングを出力

判定ルール：

• 本番環境で debug が有効/スタックトレースが返される場合 => CFG リスク

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

以下のいずれか2つ以上を提示し、観察点を明確に記述してください。

• AUTH：低権限ユーザーで保護されていると思われる action をリクエストし、アクセスが成功するか/ビジネス上の副作用が発生するかを観察
• CSRF：状態変更ルーティングに対して、CSRF token が欠落または誤っているリクエストを構築し、阻止が返されるか/ビジネスが実行され続けるかを観察

PoC 出力要件：

• 実際のルーティング/コントローラー action を含める必要があります（ルーティングマッピングまたはコードエントリポイントの証拠から抽出）
• token フィールド名/検証に必要なフィールドを含める必要があります（プロジェクトの実情のフィールド名で出力）
• 観察点（HTTP ステータスコード、応答内容の特徴、ビジネス上の副作用の有無）を説明する必要があります

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

• [ ] 出力内容：ThinkPHP 識別証拠 + AUTH/CSRF/テンプレート出力/ORM 書き込み/データベースネイティブエントリポイント/デバッグ設定の6つの主要なチェック結果
• [ ] 各リスクには以下が含まれます：マッピングタイプコード + 位置の証拠 + 可観測検証フレームワーク + 修正提案