php-logic-audit

PHP Business Logic Vulnerability Audit (php-logic-audit)

Analyze defects related to "business process correctness" in PHP projects. Key coverage:

• Mass Assignment (bulk assignment leading to unauthorized fields being written)
• Flow bypass (missing prerequisite state or bypassable validation)
• State machine defects (incomplete/rollbackable/inconsistent state updates)
• Race conditions (TOCTOU, multiple disbursements due to concurrency, duplicate charges, etc.)
• Missing business-layer authorization checks (interlinked with IDOR, but with more focus on business ownership consistency)
• Payment/refund/async task ordering vulnerabilities (async callbacks can be forged or processed repeatedly)

Severity Rating and Numbering

• See details:shared/SEVERITY_RATING.md
• Vulnerability ID:{C/H/M/L}-LOGIC-{序号}

Mandatory Evidence (Required)

Each logic vulnerability must provide:

1. Triggering route and method (actual route/HTTP method)
2. State preconditions (what conditions the attacker must satisfy: login state/role/resource state)
3. Defect location (business service/controller/callback handler/queue consumption logic)
4. State change chain (from input -> validation -> database write/external service call -> state update)
5. Evidence related to concurrency/timing (if any: transaction boundaries/locks/unique constraints/idempotency handling)

Mass Assignment Audit (Required)

Must detect:

• Whether there is behavior that directly writes $_POST/Request->all()/request()->all() into a model or database
• Whether there is a missing whitelist that allows updating sensitive fields (such as role/is_admin/status/price/owner_id
• Whether the ORM/framework's fill protection is enabled (e.g., Laravel $fillable/$guarded）

Race Condition and Idempotency Audit (Required)

Must detect:

• Whether the same operation may be executed multiple times under concurrency (charging, shipping, upgrading, claiming)
• Whether it relies on "check first, then write" (TOCTOU) and lacks transactions/row locks
• Whether there is an idempotency key and deduplication (e.g., payment_id/nonce)

Flow Bypass Audit (Required)

Must detect:

• Whether validation exists only on the prerequisite page but is missing on the backend
• Whether it relies on frontend hidden fields/buttons to restrict the flow
• Whether the callback interface has reliable authentication and signature verification, and whether it can be called repeatedly

Type Comparison Bypass and Weak Typing Vulnerabilities (Required)

Weak typing/loose comparison in PHP often leads to authentication/authorization/business decision bypasses, and must be audited:

• Whether there is use of ==/!=(non-strict comparison) for authentication decisions, state decisions, or permission checks
• Whether there is in_array($x, $arr) with strict mode not set (third parameter), leading to type conversion bypass
• Whether there is array_search、strpos and other results not handled correctly when participating in conditional judgments (e.g., strpos returning 0 is treated as false, or mixed use with strings/numbers)
• Whether there is md5/sha1 used for "authentication verification" and directly using == to compare digests (must identify whether it uses hash_equals）
• Whether token/JWT/verification-code comparison logic uses an approach that can be inferred via timing or bypassed via type juggling (comparison functions/conditional expressions require evidence)

Each weak-typing vulnerability must provide:

• Location evidence (comparison expression/conditional statement/location of related function call)
• Source (how user input enters the comparison)
• Sink (branch result caused by incorrect comparison: allow/bypass/incorrect state)
• PoC (request sequence or payload, at least including "how the comparison value is constructed to trigger the bypass")

Authentication/account workflow logic (required)

The security of business processes related to "state transitions" must be audited:

• Whether the password reset token is single-use, whether it has a clear expiration time, and whether it is bound to the user
• Whether OTP/verification codes can be replayed (whether the same token/nonce can be reused)
• Whether login failure count/account lockout/rate limiting is implemented and occurs on the backend
• Account enumeration: whether error messages/response codes/timing differences leak whether a user exists
• Whether payment/refund callbacks are idempotent (whether the same transaction is credited/issued repeatedly)

The PoC must provide a request sequence of at least two steps: first establish the prerequisite state, then trigger the state transition action, and annotate the observation points (database fields/response codes/redirects/callback execution count).

PoC (mandatory)

A logic vulnerability PoC must provide a "request sequence":

• At least two steps: trigger the prerequisite condition -> trigger the vulnerability action (and annotate the actual route)
• If it is a race condition vulnerability: provide the concurrent request method and observation points (for example, the steps for sending two curls simultaneously)

Report output

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

Entry template (mandatory)

• Location evidence
• Defect description (must be based on code semantics, not just general wording)
• State change chain
• Exploitable prerequisites
• Request sequence PoC
• Remediation recommendations (including: allowlist/transaction/lock/idempotency/backend secondary validation)