php-logging-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PHP 安全日志与监控审计（php-logging-audit）

PHP Security Logging and Monitoring Audit (php-logging-audit)

分析 PHP 项目在“安全可观测性”方面的代码与配置缺陷。核心目标不是泛化“要不要打日志”，而是识别可落地的问题：攻击者可否通过输入污染日志、系统是否把敏感信息写入日志、关键安全事件是否缺失、以及告警/审计链是否被破坏。

Analyzes code and configuration defects in PHP projects regarding "security observability". The core goal is not to generalize "whether to log or not", but to identify actionable issues: whether attackers can pollute logs through input, whether the system writes sensitive data to logs, whether key security events are missing, and whether the alert/audit chain is broken.

分级与编号

Rating and Numbering

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

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

覆盖范围（必做：必须逐项检查并输出证据）

Coverage (Mandatory: Must check each item and output evidence)

本 skill 必须覆盖下列四类缺陷，并为每一类给出“证据点 + 影响 + 可利用性分析 + 修复建议”：

This skill must cover the following four types of defects, and provide "evidence points + impact + exploitability analysis + remediation recommendations" for each type:

1) 安全事件审计缺失（Audit Gap）

1) Audit Gap

识别缺失的安全事件日志点，例如（以项目实际入口为准）：

登录失败/成功与账号枚举相关失败原因记录（避免泄露敏感细节）
权限拒绝/越权尝试（拒绝原因可抽象化记录）
密码重置、邮箱变更、管理员角色变更、2FA 变更等关键账户事件
敏感操作（导出数据、下载密钥、删除/修改权限、批量导入）
CSRF 校验失败、会话失效、注销成功等安全相关状态变化

要求输出：

“应当记录哪些事件”（按你在源码里识别到的功能点映射）
“实际写日志的位置是否存在/是否被绕过”（给出证据）
缺失导致的真实后果推演（例如审计不可用、事后无法追溯、告警无法触发）

Identify missing security event logging points, e.g., (based on actual project entry points):

Records of login failure/success and account enumeration-related failure reasons (avoid leaking sensitive details)
Permission denial/authorization bypass attempts (denial reasons can be recorded in abstract form)
Key account events such as password reset, email change, admin role change, 2FA change
Sensitive operations (data export, key download, permission deletion/modification, batch import)
Security-related status changes such as CSRF validation failure, session invalidation, successful logout

Required outputs:

"Which events should be recorded" (mapped according to functional points identified in the source code)
"Whether the actual logging location exists/is bypassed" (provide evidence)
Deduction of real consequences caused by the gap (e.g., audit unavailability, inability to trace after incidents, failure to trigger alerts)

2) 敏感信息写入日志（Sensitive Data in Logs）

2) Sensitive Data in Logs

识别任何可能把敏感数据写入日志的路径：

```
Authorization
```
头、Cookie、
```
session_id
```
、JWT 原文
密码/验证码/恢复 token/一次性口令
用户隐私数据在失败栈或 debug 输出中被原样打印
将请求体/参数（尤其是包含密钥字段）直接拼进日志消息

要求输出：

敏感信息来源（来自哪些变量/请求字段）
写日志的调用点与 message 构造方式
日志的落地介质（文件路径/系统日志通道/日志库）

Identify any paths that may write sensitive data to logs:

```
Authorization
```
header, Cookie,
```
session_id
```
, JWT raw content
Passwords/verification codes/recovery tokens/one-time passwords
User privacy data printed as-is in failure stacks or debug outputs
Directly splicing request bodies/parameters (especially those containing key fields) into log messages

Required outputs:

Source of sensitive data (from which variables/request fields)
Log writing call points and message construction methods
Log落地介质 (file path/system log channel/log library)

3) 日志注入与伪造（Log Injection / Forging）

3) Log Injection / Forging

识别“用户可控字符串进入日志消息但未做控制字符净化”的问题：

```
\r
```
/
```
\n
```
进入日志消息导致日志行拆分
可能造成伪造时间戳、级别、请求路径等“假条目”
若日志格式使用 JSON 或键值对，检查是否存在转义缺陷造成结构被破坏

要求输出：

哪些字段可控（GET/POST/Headers/Body/Cookie）
注入进入点（日志 message 拼接点）
是否存在过滤/归一化（尤其是换行与控制字符处理）

Identify issues where "user-controllable strings enter log messages without control character purification":

```
\r
```
/
```
\n
```
entering log messages leading to log line splitting
Potential forgery of timestamps, levels, request paths, etc., as "fake entries"
If JSON or key-value pairs are used for log formatting, check for escape defects that cause structural damage

Required outputs:

Which fields are controllable (GET/POST/Headers/Body/Cookie)
Injection entry points (log message splicing points)
Whether filtering/normalization exists (especially handling of line breaks and control characters)

4) 日志与告警链路缺陷（Monitoring & Alert Gaps）

4) Monitoring & Alert Gaps

识别监控链路缺口（以代码/配置能证明的为准）：

关键安全事件只记录 debug/info，未进入可告警通道
日志级别与告警规则缺失（例如 production 关闭了安全告警 channel）
错误处理吞掉异常导致关键事件没有被写入

要求输出：

你在源码里定位到的日志级别/通道/handler 配置证据
这些证据如何导致告警无法触发或取不到关键证据

Identify monitoring link gaps (based on code/configuration evidence):

Key security events are only recorded at debug/info level and do not enter alertable channels
Missing log levels and alert rules (e.g., production environment disables security alert channels)
Error handling swallows exceptions leading to failure to write key events

Required outputs:

Evidence of log level/channel/handler configuration located in the source code
How these evidence lead to failure to trigger alerts or retrieve key evidence

识别逻辑（必做）

Identification Logic (Mandatory)

日志写入 Sink（代码）

Log Writing Sink (Code)

必须识别以下日志相关 API（按项目实际替换）：

PHP：
```
error_log({value})
```
系统：
```
syslog({value})
```

PSR-3/框架：

->info({value})

->warning({value})

->error({value})

->critical({value})

->debug({value})

Laravel/Symfony/自定义封装：
```
Log::{value}({value})
```
、
```
logger->{value}
```
或项目自己的 logger wrapper
Monolog：
```
Monolog\Logger
```
及 handler/channel 相关配置

Must identify the following log-related APIs (replace according to actual project):

PHP:
```
error_log({value})
```
System:
```
syslog({value})
```

PSR-3/Frameworks:

->info({value})

->warning({value})

->error({value})

->critical({value})

->debug({value})

Laravel/Symfony/Custom Wrappers:
```
Log::{value}({value})
```
,
```
logger->{value}
```
or the project's own logger wrapper
Monolog:
```
Monolog\Logger
```
and handler/channel related configurations

消息构造与可控性（数据流）

Message Construction and Controllability (Data Flow)

对每个日志写入点，必须追踪至少一条链：

Source（请求字段/用户输入/敏感 token 来源） -> 中间变量处理（拼接、格式化、json_encode、模板字符串） -> Sink（最终写入日志的 message 参数）

并输出：

可控字段名（或 JSON 路径）
进入日志前是否有净化（换行/控制字符/敏感字段脱敏）
是否有条件分支导致“只有某些分支才写日志”（写日志绕过）

For each log writing point, must track at least one chain:

Source (request fields/user input/sensitive token source) -> Intermediate variable processing (splicing, formatting, json_encode, template strings) -> Sink (final message parameter written to logs)

And output:

Controllable field names (or JSON paths)
Whether purification exists before entering logs (line break/control character/sensitive field desensitization)
Whether there are conditional branches leading to "logging only in certain branches" (logging bypass)

PoC（必做：可观测验证框架）

PoC (Mandatory: Observable Verification Framework)

由于“日志缺陷”往往需要观察日志输出，你必须给出可观测 PoC 框架（可执行或可手动验证），至少包括以下两类其一：

使用真实路由触发日志写入，并说明预期日志中出现的字段/格式变化
使用构造 payload 注入换行/控制字符，说明预期日志会被拆行或出现伪造片段

PoC 输出要求：

必须包含真实路由（优先从

routes_{timestamp}.md

替换；独立落盘见

route_mapping/routes_{timestamp}.md

，约定见

shared/IO_PATH_CONVENTION.md

）

必须写出用于触发的请求头与 body/参数（至少包含一个会进入日志消息的可控字段）
必须说明你要在日志文件/控制台/系统日志中观察什么（例如某字段是否原样出现）

Since "log defects" often require observing log outputs, you must provide an observable PoC framework (executable or manually verifiable), including at least one of the following two types:

Use real routes to trigger log writing, and explain expected field/format changes in logs
Use constructed payloads to inject line breaks/control characters, and explain expected log line splitting or forged fragments

PoC output requirements:

Must include real routes (prefer replacement from
```
routes_{timestamp}.md
```
; independent storage see
```
route_mapping/routes_{timestamp}.md
```
, convention see
```
shared/IO_PATH_CONVENTION.md
```
)
Must write request headers and body/parameters used for triggering (at least one controllable field that will enter log messages)
Must explain what to observe in log files/console/system logs (e.g., whether a certain field appears as-is)

报告输出

Report Output

输出到：

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

Output to:

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

漏洞条目模板（强制）

Vulnerability Entry Template (Mandatory)

每条漏洞必须遵循以下结构（不得省略）：

markdown

undefined

Each vulnerability must follow the following structure (no omissions allowed):

markdown

undefined

[{等级前缀}-LOG-{序号}] {风险标题}

[{Severity Prefix}-LOG-{Serial Number}] {Risk Title}

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

Item	Information
Severity Level	{🔴/🟠/🟡/🔵} (CVSS {score})
Reachability (R)	{0-3} - {Reason}
Impact Scope (I)	{0-3} - {Reason}
Exploit Complexity (C)	{0-3} - {Reason}
Exploitability	✅ Confirmed / ⚠️ Pending Verification / ❌ Not Exploitable / 🔍 Environment Dependent
Location	{file}:{line} ({Function/Class})

漏洞类型与证据点

Vulnerability Type and Evidence Points

缺陷类别：{Audit Gap / Sensitive Data in Logs / Log Injection / Monitoring Gap}
证据点 A（日志写入调用点）：{file}:{line} 说明
证据点 B（消息构造/可控字段进入点）：{file}:{line} 说明
证据点 C（净化/脱敏是否存在）：{file}:{line} 说明（如无则写“未发现脱敏/未发现过滤”并给出搜索结论）

Defect Category: {Audit Gap / Sensitive Data in Logs / Log Injection / Monitoring Gap}
Evidence Point A (Log Writing Call Point): {file}:{line} Description
Evidence Point B (Message Construction/Controllable Field Entry Point): {file}:{line} Description
Evidence Point C (Purification/Desensitization Existence): {file}:{line} Description (write "No desensitization found/No filtering found" and provide search conclusion if none)

数据流链（Source -> Transform -> Sink）

Data Flow Chain (Source -> Transform -> Sink)

（逐行写出：请求输入如何被读取/解析/格式化 -> 是否进入日志 message -> 最终写入日志）

(Write line by line: How request input is read/parsed/formatted -> Whether it enters log message -> Finally written to logs)

可利用前置条件

Preconditions for Exploitation

鉴权要求：{无需/需登录/需特定权限}
输入可控性：{完全可控/条件可控/不可控}
触发条件：{分支/错误路径/异常路径/日志级别条件}
可观测性：{日志落地位置是否可读/是否在生产可见/是否需要运维权限}

Authentication Requirement: {None/Requires Login/Requires Specific Permissions}
Input Controllability: {Fully Controllable/Conditionally Controllable/Uncontrollable}
Trigger Condition: {Branch/Error Path/Exception Path/Log Level Condition}
Observability: {Whether log storage location is readable/Visible in production/Requires operation and maintenance permissions}

验证 PoC（强制，可观测）

Verification PoC (Mandatory, Observable)

http

{HTTP Method} {真实路由与完整参数} HTTP/1.1
Host: {host}
{必要 Header/Session/JWT/Cookie}

{Payload}

（PoC 之后你需要观察的日志现象：{明确写出预期日志内容/格式变化/是否出现换行拆分}）

http

{HTTP Method} {Real Route and Complete Parameters} HTTP/1.1
Host: {host}
{Necessary Header/Session/JWT/Cookie}

{Payload}

(Log phenomenon to observe after PoC: {Clearly write expected log content/format changes/Whether line splitting occurs})

建议修复

Remediation Recommendations

安全写法要点：敏感字段脱敏、控制字符净化、structured logging、日志级别与告警映射
代码搜索语句：使用
```
rg
```
定位所有日志写入与 message 构造相关代码块

undefined

Key Security Practices: Sensitive field desensitization, control character purification, structured logging, log level and alert mapping
Code Search Statement: Use
```
rg
```
to locate all code blocks related to log writing and message construction

undefined

输出完整性检查（强制）

Output Completeness Check (Mandatory)

每条漏洞都包含：编号、等级、位置、数据流链、可利用前置条件、可观测 PoC、修复建议
日志注入类问题必须明确使用控制字符 payload（至少包含换行注入场景）
敏感信息类问题必须明确指出敏感字段来源与写入位置
审计缺失类问题必须明确指出“应该记录但未记录”的对照逻辑（基于源码事件点推断，而不是泛泛而谈）

undefined

Each vulnerability includes: ID, level, location, data flow chain, preconditions for exploitation, observable PoC, remediation recommendations
Log injection issues must explicitly use control character payloads (at least including line break injection scenarios)
Sensitive data issues must clearly indicate sensitive field sources and writing locations
Audit gap issues must clearly indicate the comparison logic of "should be recorded but not recorded" (inferred based on source code event points, not general statements)

undefined