php-filesystem-audit

PHP filesystem operation audit (php-filesystem-audit)

Analyze key filesystem operations in PHP projects, with particular attention to how these operations interact with:

• Path validation/normalization failures (directory traversal, missing basePath)
• Drop-point write/read/include chains
• Post-write triggering (executability, includability)
• Race conditions (TOCTOU)

to increase real exploitability.

Coverage (required)

The following points must be covered and output with "evidence point + risk explanation + exploitability judgment":

1) Creation/directory operations

• mkdir($path, $mode, $recursive)
• rmdir($path)
• touch($path)
• tmpfile() / tempnam()
• Framework-wrapped directory creation (such as the underlying wrapper of Storage::put/ensureDirectory , if identifiable)

2) Permission/ownership changes (often used in privilege escalation chains or to bypass execution policies)

• chmod/chown/chgrp
• umask

3) Link and redirection drop points (common symlink/hardlink bypasses)

• symlink($target, $link)
• link($target, $link)
• readlink($path)

4) Deletion and cleanup (combined with TOCTOU or overwrite chains)

• unlink($path)
• unlink/rename variant deletion
• rename($src, $dest)(when used for drop-point modification, special attention to TOCTOU is required)
• copy/move variants (when they appear as a "drop-point preparation step")

5) Path races and TOCTOU (must be audited separately)

For code patterns with "check-use separation", provide a judgment:

• Whether after if (realpath/canonicalize + 前缀校验) there is repeated join/open/write in some branch/exception handling (the path may change)
• Whether there is first checking writability/then writing, or first checking then performing file operations
• Whether there is symlink resolution/inconsistent resolution (the resolved path at check time differs from the actual open time)

Key output requirements (mandatory)

Each finding must include:

1. Location evidence: file path and function/call site (include line numbers if possible; if no line number can be found, mark as to be located)

2. Operation type: create/permission/link/delete/rename/copy, etc.

3. Source of path control: whether the path parameter comes from GET/POST/SESSION/config or is hardcoded

4. Relationship to the chain (at least one must be selected and explained):

   • Associated with the executability or includability of the WRITE/UPLOAD drop point
   • Associated with FILE(read/include) or ARCHIVE(extraction drop point)
   • Associated with authentication/resource ownership (for example, only the admin directory has write permission but it is bypassed)
   • Associated with a TOCTOU race (the path may be replaced between the check point -> use point)

5. Exploitability judgment:

   • ✅ Confirmed: it can be proven that the key precondition of the exploitation chain is provided by this filesystem operation (or forms a closed loop with WRITE/UPLOAD/FILE evidence)
   • ⚠️ To be verified: a risk exists, but some key precondition is missing or trace/analysis evidence is insufficient
   • ❌ Not exploitable: strong constraints exist (baseDir allowlist is in effect, resolved path consistency protection, permissions are fixed and cannot be changed, the race window is eliminated)
   • 🔍 Environment-dependent: depends on a specific filesystem/permissions/concurrent timing/server directory structure

6. Triggerability constraints (mandatory):

   • Only generate vulnerability entries for file system operations that "can be triggered by a specific HTTP route/entry point," and it must be possible to provide the real route and complete parameters for the PoC.
   • If the specific route entry point cannot be located (such as a pure background task/scheduled task/command-line tool whose entry point cannot be traced), this FS risk can only be noted in the report as "entry point could not be located, entry generation skipped (trigger path to be supplied manually)," and a non-executable PoC must not still be forcibly output according to the vulnerability entry template.

Report Output

Output to:

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

Vulnerability numbering convention (recommended: FS)

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

Vulnerability entry template (mandatory)

Each finding must follow the structure below (must not be omitted):

### [{等级前缀}-FS-{序号}] 文件系统操作链风险（权限/链接/删除/TOCTOU/路径控制）

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

#### 数据流链（Source → Path Control → FS Operation → Chain Influence）
（逐行写出：用户/上下文输入如何进入路径控制变量、是否经过 realpath/canonicalize 及前缀校验、最终如何落到 mkdir/chown/symlink/unlink/rename/等文件系统操作参数、以及该文件系统操作如何影响后续链路能力：WRITE/UPLOAD/FILE/ARCHIVE/CMD/TPL/EXPR/DESER 等）

#### 可利用前置条件
- 鉴权要求：{无需/需登录/需特定权限}
- 输入可控性：{完全可控/条件可控/不可控}
- 触发条件：{分支/异常路径/需要特定文件系统权限/需要竞态窗口/需要特定目录结构}
- 链路承接：{它如何为其它 sink 类别提供“可利用性增强”说明（写入落点/可包含性/权限提升/绕过执行策略/触发竞态）}

#### 验证 PoC（强制：可观测验证框架）
```http
{HTTP Method} {真实路由与完整参数} HTTP/1.1
Host: {host}
{必要 Header/Session/JWT/Cookie}

{Payload}

PoC output/observation point (must be clearly stated):

1. Whether the file system state change caused by this FS operation is observable (for example: file creation under the target path/permission changes/link target changes/deletion result/existence of the final landing point).
2. If it is TOCTOU: demonstrate the observable phenomenon that "the resolved path at the check point and the use point are inconsistent/the window can be exploited" (for example, concurrent triggering causes the final landing point to change).

Evidence references (mandatory: from source code snippets)

It must contain at least three evidence snippets corresponding to the location (key lines may be directly restated in the text):

1. FS operation call site (mkdir/chmod/chown/symlink/unlink/rename, etc.) and parameter positions (file:line)
2. Path validation/normalization logic (realpath/canonicalize/baseDir prefix validation) and its relationship to the FS operation (within the same function or across functions)
3. Path control source (GET/POST/SESSION/hardcoded configuration, etc.) and its propagation chain

Recommended fix

• Path validation and actual use must be bound to the same resolved target:realpath/canonicalize and then use the same value for open/rename/write (to avoid TOCTOU)
• It is forbidden to split "validate first, use later" for paths that can be influenced by an attacker; if splitting is necessary, it should be completed within the same system call/same file descriptor context
• For symlink/hardlink: enable anti-link policy at the target landing point (disable following symbolic links when the platform supports it, or verify consistency based on inode/file descriptor)
• Permission changes must be minimized and ensured not to be influenceable by users; prevent attackers from controlling chmod/chown paths

Code search statements (mandatory)

rg -n "(mkdir\\(|rmdir\\(|touch\\(|tmpfile\\(|tempnam\\(|chmod\\(|chown\\(|chgrp\\(|symlink\\(|readlink\\(|link\\(|unlink\\(|rename\\(|copy\\(|symlink\\()" .
rg -n "(realpath\\(|canonicalize\\(|dirname\\(|basename\\(|baseDir|dest(path)?|target(path)?)" .

Fix recommendations (mandatory key points)

• Path validation and actual use must be bound to the same resolved target:realpath/canonicalize and then use the same value for open/rename/write (to avoid TOCTOU)
• It is forbidden to split "validate first, use later" for paths that can be influenced by an attacker; if splitting is necessary, it should be completed within the same system call/same file descriptor context
• For symlink/hardlink: enable anti-link policy at the target landing point (disable following symbolic links when the platform supports it, or verify consistency based on inode/file descriptor)
• Permission changes must be minimized and ensured not to be influenceable by users; prevent attackers from controlling chmod/chown paths