jpskill.com
🛠️ 開発・MCP コミュニティ

php-logic-audit

PHP Webアプリケーションの認証・認可以外のロジック脆弱性（マスアサインメント、競合状態など）を検出し、証拠や修正案を提示するSkill。

📜 元の英語説明(参考)

PHP Web 业务逻辑漏洞审计工具。识别认证/授权以外的逻辑缺陷：Mass Assignment、流程绕过、竞态条件、状态机缺陷、支付/权限时序漏洞等，输出证据链、分级、PoC 与修复建议（禁止省略）。

🇯🇵 日本人クリエイター向け解説

一言でいうと

PHP Webアプリケーションの認証・認可以外のロジック脆弱性（マスアサインメント、競合状態など）を検出し、証拠や修正案を提示するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⬇ このSkillをダウンロード(.skill) 元のソースを見る ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

[Skill 名] php-logic-audit

PHP 業務ロジック脆弱性監査（php-logic-audit）

PHP プロジェクトにおける「業務フローの正確性」に関する欠陥を分析します。重点的にカバーする項目は以下の通りです。

  • Mass Assignment（一括代入により、権限昇格可能なフィールドが書き込まれる）
  • フローバイパス（先行状態の欠如または検証がスキップされる）
  • ステートマシン欠陥（状態更新が不完全/ロールバック可能/不整合）
  • 競合状態（TOCTOU、並行処理による複数回付与、重複引き落としなど）
  • 権限昇格を伴う業務層検証の欠如（IDOR と連携しますが、業務上の帰属の一貫性により焦点を当てます）
  • 支払い/払い戻し/非同期タスクの順序に関する脆弱性（非同期コールバックが偽造されたり、重複して処理されたりする）

分類と番号付け

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

必須の証拠（強制）

各ロジック脆弱性には、以下の情報を提供する必要があります。

  1. トリガーとなるルートとメソッド（実際のルート/HTTP メソッド）
  2. 状態の前提条件（攻撃者が満たす必要のある条件：ログイン状態/ロール/リソース状態）
  3. 欠陥箇所の位置（ビジネスサービス/コントローラー/コールバックハンドラー/キュー消費ロジック）
  4. 状態変化チェーン（入力 -> 検証 -> データベースへの書き込み/外部サービス呼び出し -> 状態更新）
  5. 並行処理/時系列に関連する証拠（もしあれば：トランザクション境界/ロック/一意制約/冪等処理）

Mass Assignment 監査（必須）

以下の項目を必ず検査してください。

  • $_POST/Request->all()/request()->all() を直接モデルまたはデータベースに書き込む動作が存在するかどうか
  • 敏感なフィールド（例：role/is_admin/status/price/owner_id）の更新を許可するホワイトリストの欠如が存在するかどうか
  • ORM/フレームワークのフィル保護が有効になっているか（例：Laravel の $fillable/$guarded）

競合と冪等性監査（必須）

以下の項目を必ず検査してください。

  • 同一操作が並行処理下で複数回実行されるかどうか（引き落とし、発送、アップグレード、受け取り）
  • 「先に照会してから書き込む」（TOCTOU）に依存しており、トランザクション/行ロックが欠如しているかどうか
  • 冪等キーと重複排除（例：payment_id/nonce）が存在するかどうか

フローバイパス監査（必須）

以下の項目を必ず検査してください。

  • 前提ページでのみ検証が行われ、バックエンドでの検証が欠如しているかどうか
  • フローを制限するためにフロントエンドの隠しフィールド/ボタンに依存しているかどうか
  • コールバックインターフェースの認証と署名が信頼できるか、重複して呼び出される可能性があるかどうか

型比較バイパスと弱型付けの脆弱性（必須）

PHP における弱型付け/緩い比較は、認証/認可/業務判断のバイパスを引き起こすことが多いため、以下の項目を監査する必要があります。

  • ==/!=（非厳密比較）を使用して認証判断、状態判断、または権限検証を行っているかどうか
  • in_array($x, $arr) で厳密モード（第3引数）が設定されておらず、型変換バイパスを引き起こしているかどうか
  • array_search、strpos などの結果が条件判断に関与する際に正しく処理されていないかどうか（例：strpos が 0 を返したときに false と見なされる、または文字列/数値と混用される）
  • md5/sha1 が「認証検証」に使用され、ダイジェストを直接 == で比較しているかどうか（hash_equals が使用されているかを識別する必要があります）
  • token/JWT/検証コードの比較ロジックが、時系列推測または型変換によってバイパスされる可能性のある方法（比較関数/条件式は証拠化が必要）を使用しているかどうか

各弱型付けの脆弱性には、以下の情報を提供する必要があります。

  • 位置の証拠（比較式/条件文/関連する関数呼び出しの位置）
  • Source（ユーザー入力がどのように比較に到達するか）
  • Sink（誤った比較によって引き起こされる分岐結果：通過/バイパス/エラー状態）
  • PoC（リクエストシーケンスまたはペイロード。少なくとも「比較値をどのように構築してバイパスをトリガーするか」を含む）

認証/アカウントワークフローロジック（必須）

「状態遷移」に関連する業務フローのセキュリティを監査する必要があります。

  • パスワードリセットトークンが一度のみ使用されるか、明確な有効期限があるか、ユーザーと紐付けられているか
  • OTP/検証コードにリプレイが存在するか（同一の token/nonce が繰り返し使用できるか）
  • ログイン失敗回数/アカウントロック/レート制限が実装されており、バックエンドで発生しているか
  • アカウント列挙：エラーメッセージ/応答コード/所要時間の差異がユーザーの存在を漏洩するか
  • 支払い/払い戻しコールバックが冪等であるか（同一の transaction が重複して計上/重複して付与されるか）

PoC は、少なくとも2段階のリクエストシーケンスを提供する必要があります。まず前提状態を確立し、次に状態遷移アクションをトリガーし、観測点（データベースフィールド/応答コード/リダイレクト/コールバック実行回数）を明記します。

PoC（強制）

ロジック脆弱性の PoC は「リクエストシーケンス」を提供する必要があります。

  • 少なくとも2段階：前提条件のトリガー -> 脆弱性アクションのトリガー（実際のルートを明記）
  • 競合脆弱性の場合は：並行リクエストの方法と観測点（例：2つの curl を同時に送信する手順）を提供します。

レポート出力

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

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

  • 位置の証拠
  • 欠陥の説明（コードのセマンティクスに基づいて記述し、一般的な表現のみを使用しないこと）
  • 状態変化チェーン
  • 利用可能な前提条件
  • リクエストシーケンス PoC
  • 修正提案（ホワイトリスト/トランザクション/ロック/冪等性/バックエンドでの二次検証を含む）
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

PHP 业务逻辑漏洞审计（php-logic-audit）

分析 PHP 项目中“业务流程正确性”相关缺陷。重点覆盖：

  • Mass Assignment（批量赋值导致可越权字段被写入）
  • 流程绕过（前置状态缺失或校验可被跳过）
  • 状态机缺陷（状态更新不完整/可回滚/不一致）
  • 竞态条件（TOCTOU、并发导致多次发放、重复扣款等）
  • 越权的业务层校验缺失（与 IDOR 联动，但更关注业务归属一致性）
  • 付款/退款/异步任务顺序漏洞（异步回调可被伪造或重复处理）

分级与编号

  • 详见：shared/SEVERITY_RATING.md
  • 漏洞编号：{C/H/M/L}-LOGIC-{序号}

必检证据（强制）

每条逻辑漏洞必须提供：

  1. 触发路由与方法（真实路由/HTTP 方法）
  2. 状态前置条件（攻击者需要满足哪些条件：登录态/角色/资源状态）
  3. 缺陷点位置（业务服务/控制器/回调 handler/队列消费逻辑）
  4. 状态变化链（从输入 -> 校验 -> 写库/调用外部服务 -> 状态更新）
  5. 与并发/时序相关证据（如果有：事务边界/锁/唯一约束/幂等处理）

Mass Assignment 审计（必做）

必须检测：

  • 是否存在把 $_POST/Request->all()/request()->all() 直接写入模型或数据库的行为
  • 是否存在允许更新敏感字段的白名单缺失（如 role/is_admin/status/price/owner_id
  • ORM/框架的填充保护是否启用（例如 Laravel $fillable/$guarded）

竞态与幂等审计（必做）

必须检测：

  • 同一操作是否在并发下被执行多次（扣款、发货、升级、领取）
  • 是否依赖“先查再写”（TOCTOU）且缺少事务/行锁
  • 是否有幂等键与去重（如 payment_id/nonce）

流程绕过审计（必做）

必须检测：

  • 是否只在前置页面校验但后端缺少校验
  • 是否依赖前端隐藏字段/按钮来限制流程
  • 回调接口是否鉴权与签名可靠、是否可被重复调用

类型比较绕过与弱类型漏洞（必做）

PHP 中的弱类型/宽松比较经常导致认证/授权/业务判断绕过，必须审计：

  • 是否存在使用 ==/!=（非严格比较）进行鉴权判断、状态判断或权限校验
  • 是否存在 in_array($x, $arr) 未设置严格模式（第三参），导致类型转换绕过
  • 是否存在 array_search、strpos 等结果参与条件判断时未正确处理（例如 strpos 返回 0 被当成 false，或与字符串/数字混用）
  • 是否存在 md5/sha1 用于“认证校验”且直接用 == 比较摘要（必须识别是否使用 hash_equals）
  • 是否存在 token/JWT/验证码比较逻辑使用了可被时序推断或类型胶水绕过的方式（比较函数/条件表达式需证据化）

每条弱类型漏洞必须给出：

  • 位置证据（比较表达式/条件语句/相关函数调用位置）
  • Source（用户输入如何进入该比较）
  • Sink（错误比较导致的分支结果：放行/绕过/错误状态）
  • PoC（请求序列或 payload，至少包含“对比值如何构造触发绕过”）

认证/账户工作流逻辑（必做）

必须审计与“状态迁移”相关的业务流程安全：

  • 密码重置 token 是否单次使用、是否有明确过期时间、是否与用户绑定
  • OTP/验证码是否存在重放（同一 token/nonce 是否能重复使用）
  • 登录失败次数/账户锁定/速率限制是否实现且发生在后端
  • 账户枚举：错误信息/响应码/耗时差异是否泄露是否存在用户
  • 支付/退款回调是否幂等（同一 transaction 是否重复入账/重复发放）

PoC 必须给出至少两步请求序列：先建立前置状态，再触发状态迁移动作，并标注观测点（数据库字段/响应码/重定向/回调执行次数）。

PoC（强制）

逻辑漏洞 PoC 必须给出“请求序列”：

  • 至少两步：触发前置条件 -> 触发漏洞动作（并标注真实路由）
  • 若是竞态漏洞：给出并发请求方式与观测点（例如两个 curl 同时发送的步骤）

报告输出

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

条目模板（强制）

  • 位置证据
  • 缺陷描述（必须基于代码语义，不可只用一般性话术）
  • 状态变化链
  • 可利用前置条件
  • 请求序列 PoC
  • 修复建议（包括：白名单/事务/锁/幂等/后端二次校验）