php-logic-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

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

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

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

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

Mass Assignment (overprivileged fields can be written due to batch assignment)
Process Bypass (missing preconditions or skippable validations)
State Machine Defects (incomplete/rollbackable/inconsistent state updates)
Race Conditions (TOCTOU, multiple distributions or repeated deductions caused by concurrency, etc.)
Missing Business-layer Validation for Privilege Escalation (linked with IDOR, but focuses on business ownership consistency)
Payment/Refund/Asynchronous Task Sequencing Vulnerabilities (asynchronous callbacks can be forged or repeatedly processed)

分级与编号

Severity Rating and Vulnerability ID

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

See details:
```
shared/SEVERITY_RATING.md
```
Vulnerability ID format:
```
{C/H/M/L}-LOGIC-{serial number}
```

必检证据（强制）

Mandatory Evidence Collection

每条逻辑漏洞必须提供：

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

Each logic vulnerability must provide:

Trigger Route and Method (real route/HTTP method)
Preconditions (conditions attackers need to meet: login status/role/resource status)
Defect Location (business service/controller/callback handler/queue consumption logic)
State Change Chain (from input -> validation -> database write/external service call -> state update)
Concurrency/Timing-related Evidence (if applicable: transaction boundaries/locks/unique constraints/idempotency handling)

Mass Assignment 审计（必做）

Mass Assignment Audit (Mandatory)

必须检测：

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

Must detect:

Whether there are behaviors directly writing
```
$_POST/Request->all()/request()->all()
```
to models or databases
Whether there is a missing whitelist that allows updating sensitive fields (e.g.,
```
role/is_admin/status/price/owner_id
```
)
Whether ORM/framework fill protection is enabled (e.g., Laravel
```
$fillable/$guarded
```
)

竞态与幂等审计（必做）

Race Condition and Idempotency Audit (Mandatory)

必须检测：

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

Must detect:

Whether the same operation can be executed multiple times under concurrency (deduction, delivery, upgrade, redemption)
Whether it relies on "check-then-write" (TOCTOU) without transactions/row locks
Whether there are idempotency keys and deduplication mechanisms (e.g., payment_id/nonce)

流程绕过审计（必做）

Process Bypass Audit (Mandatory)

必须检测：

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

Must detect:

Whether validation is only performed on the front-end page but missing on the back-end
Whether process restrictions rely on front-end hidden fields/buttons
Whether callback interfaces have reliable authentication and signatures, and whether they can be repeatedly called

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

Type Comparison Bypass and Weak Type Vulnerabilities (Mandatory)

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

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

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

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

Weak type/loose comparison in PHP often leads to authentication/authorization/business judgment bypasses, so the following must be audited:

Whether
```
==
```
/
```
!=
```
(non-strict comparison) is used for authentication judgment, state judgment or permission validation
Whether
```
in_array($x, $arr)
```
is used without strict mode (third parameter), leading to type conversion bypass
Whether results of
```
array_search
```
,
```
strpos
```
etc. are improperly handled when participating in condition judgments (e.g.,
```
strpos
```
returning 0 is treated as false, or mixed with strings/numbers)
Whether
```
md5/sha1
```
is used for "authentication validation" and digests are directly compared with
```
==
```
(must identify whether
```
hash_equals
```
is used)
Whether token/JWT/verification code comparison logic uses methods that can be bypassed via timing inference or type juggling (comparison functions/conditional expressions need to be evidenced)

Each weak type vulnerability must provide:

Location Evidence (comparison expression/conditional statement/relevant function call location)
Source (how user input enters the comparison)
Sink (branch result caused by incorrect comparison: pass/bypass/error state)
PoC (request sequence or payload, including at least "how to construct the comparison value to trigger bypass")

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

Authentication/Account Workflow Logic (Mandatory)

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

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

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

Must audit business process security related to "state migration":

Whether password reset tokens are single-use, have clear expiration times, and are bound to users
Whether OTP/verification codes can be replayed (whether the same token/nonce can be reused)
Whether login failure count/account lockout/rate limiting are implemented on the back-end
Account Enumeration: whether error messages/response codes/latency differences leak the existence of users
Whether payment/refund callbacks are idempotent (whether the same transaction can be repeatedly recorded/disbursed)

PoCs must provide at least a two-step request sequence: first establish preconditions, then trigger state migration actions, and mark observation points (database fields/response codes/redirects/callback execution counts).

PoC（强制）

PoC (Mandatory)

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

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

PoCs for logic vulnerabilities must provide a "request sequence":

At least two steps: trigger preconditions -> trigger vulnerability action (mark real routes)
For race condition vulnerabilities: provide concurrent request methods and observation points (e.g., steps for sending two curl requests simultaneously)

报告输出

Report Output

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

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

条目模板（强制）

Entry Template (Mandatory)

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

Location Evidence
Defect Description (must be based on code semantics, general statements are not allowed)
State Change Chain
Exploitable Preconditions
Request Sequence PoC
Remediation Suggestions (including: whitelist/transaction/lock/idempotency/back-end revalidation)