php-expr-audit

PHP expression injection (non-template) audit (php-expr-audit)

Analyze PHP project source code to identify "expression evaluation/compilation" entry points: user-controllable expression strings are passed into the expression engine (or PHP language-level code execution functions), thereby altering conditional judgments, routing decisions, permission expressions, or executing sensitive semantics (Expression Injection/code injection class).

Grading and numbering

• See:shared/SEVERITY_RATING.md
• Vulnerability number:{C/H/M/L}-EXPR-{序号}

EXPR Sink (required)

Identify the evaluation/compilation entry points of the expression engine (preferred), as well as PHP language-level "string as code" execution functions:

• ExpressionLanguage->evaluate({value})
• ExpressionLanguage->compile({value}) subsequent execution/evaluation use point
• eval($code)(when $code can be controlled by the user)
• assert($assertion)(when $assertion is a string and can be controlled by the user)
• preg_replace({value}, $replacement, {value}) using the deprecated /e modifier (when replacement is controllable)
• and equivalent "expression parsing/evaluation" engines (project-encapsulated evaluate/parse/compile methods, as long as the expression string is ultimately taken as input)

Mandatory evidence points (required, trace contract alignment)

Each suspected EXPR vulnerability must item by item reference php-route-tracer in the trace ## 9) Sink Evidence Type Checklist the EXPR linecorresponding evidence point ID:

1. EVID_EXPR_EVAL_ENTRY: evidence of the location of the expression parsing/compilation/evaluation entry point
2. EVID_EXPR_EXPR_CONTROL: evidence mapping whether the expression string comes from user-controllable input
3. EVID_EXPR_EXEC_CHAIN_ENTRY: evidence of subsequent use of the expression evaluation chain (how the evaluation result enters sensitive semantics/security-critical branches, or the final execution point)

Confirmation of controllability and injection semantics (required)

Must output and determine:

• Where the expression string comes from: request fields/JSON fields/parameters concatenated and then used as expression input
• Whether a whitelist/sandbox exists: whether functions, variables, constants, and types are restricted; whether the expression syntax is rejected or replaced
• Whether "the evaluation result enters security-critical logic" exists: for example, entering if/filter conditions, permission determination, expression execution outside templates, etc.
• Whether branch bypass exists: some branches do not restrict expressions, or sanitize only part of the input

Tracer trigger conditions (required)

Trigger when any condition is met php-route-tracer(or equivalent deep tracing):

• The expression string enters evaluate/compile only after multiple layers of functions/JSON decoding/concatenation
• The expression engine evaluation result participates in security-critical conditions or sensitive operations (must be traceable in the trace)
• Expression restriction logic has conditional branches (some branches have no restrictions, or the restrictions can be bypassed)

Report output

Output to:

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

Vulnerability entry template (mandatory)

Each EXPR injection vulnerability must include the following structure:

### [{等级前缀}-EXPR-{序号}] 表达式注入漏洞（非模板）

| 项目 | 信息 |
|------|------|
| 严重等级 | {🔴/🟠/🟡/🔵} (CVSS {score}) |
| 可达性 (R) | {0-3} - {理由} |
| 影响范围 (I) | {0-3} - {理由} |
| 利用复杂度 (C) | {0-3} - {理由} |
| 可利用性 | ✅ 已确认 / ⚠️ 待验证 / ❌ 不可利用 / 🔍 环境依赖 |
| 位置 | {file}:{line} ({Function}) |

#### 数据流链（Source → Sink）
(按路由逐行写出：输入读取 -> 表达式字符串构造 -> evaluate/compile 入口 -> 求值结果进入敏感语义，禁止省略)

#### 可利用前置条件
- 鉴权要求：{无需/需登录/需特定权限}
- 输入可控性：{完全可控/条件可控/不可控}
- 触发条件：{分支/异常/环境依赖}
- 沙箱/白名单可靠性：{已可靠防护/防护缺失/防护可绕过}

#### 证据引用（强制：来自 php-route-tracer）
- `EVID_EXPR_EVAL_ENTRY`：{对应证据要点简述}
- `EVID_EXPR_EXPR_CONTROL`：{对应证据要点简述}
- `EVID_EXPR_EXEC_CHAIN_ENTRY`：{对应证据要点简述}

#### 验证 PoC（强制：给出可执行请求）
```http
{HTTP Method} {真实路由与完整参数} HTTP/1.1
Host: {host}
{必要 Cookie/Auth}

{Payload}

PoC generation strategy (must be clearly written):

• Step 1: Use a "probe payload" to prove that the expression is indeed evaluated (for example, arithmetic result, change in conditional branch result, difference in return value)
• Step 2: After the detection is confirmed, construct an "injection payload" to prove that security-critical semantics can be changed (such as bypassing filtering/changing the result of a permission check). If it must rely on a specific engine function allowlist, mark it as 🔍环境依赖/⚠️待验证, but still provide a feasible attempt method

Recommended fix

• Prohibit passing user input directly as an expression string to evaluate/compile
• Use a strict allowlist: only allow fixed expression templates + parameter placeholders (and perform type/range validation on parameters)
• Enable a sandbox policy for the expression engine: restrict functions/variables/access scope; disable dangerous operations (if the engine supports it)
• Adopt a rejection policy for expression syntax (for example, reject injected control characters) and specify the rejection point locations
• Provide code search statements (rg) to locate all evaluate/compile entry points and expression string construction points

## tracer 证据缺失处理（强制）
- 若 trace 契约的 EXPR 行中任一关键证据点（`EVID_EXPR_EVAL_ENTRY / EVID_EXPR_EXPR_CONTROL / EVID_EXPR_EXEC_CHAIN_ENTRY`）缺失或无法对应到本条漏洞：状态只能标记为 `⚠️待验证`，不得直接给出 `✅已确认可利用`。