php-logging-audit

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

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

Grading and Numbering

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

Coverage (Mandatory: must check item by item and output evidence)

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

1) Missing Security Event Auditing (Audit Gap)

Identify missing security event log points, for example (based on the project's actual entry points):

• Login failure/success and account enumeration-related failure reason logging (avoid leaking sensitive details)
• Permission denial/unauthorized access attempts (denial reasons may be logged in abstracted form)
• Key account events such as password reset, email change, administrator role change, 2FA change, etc.
• Sensitive operations (data export, key download, permission deletion/modification, bulk import)
• Security-related state changes such as CSRF validation failure, session invalidation, successful logout, etc.

Required output:

• "Which events should be logged" (mapped according to the functionality points you identified in the source code)
• "Whether the actual logging location exists/is bypassed" (provide evidence)
• Deduction of real consequences caused by the omission (e.g., auditing unavailable, no post-incident traceability, alerts cannot be triggered)

2) Sensitive Information Written to Logs (Sensitive Data in Logs)

Identify any paths that may write sensitive data to logs:

• Authorization headers, Cookies,session_id, raw JWT
• Passwords/verification codes/recovery tokens/one-time passwords
• User privacy data printed as-is in failure stacks or debug output
• Directly concatenating request bodies/parameters (especially those containing secret key fields) into log messages

Required output:

• Sensitive information sources (from which variables/request fields)
• Logging call points and how the message is constructed
• The medium where logs are stored (file path/system log channel/logging library)

3) Log Injection and Forging (Log Injection / Forging)

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

• \r / \n entering log messages causes log line splitting
• May cause forged timestamps, levels, request paths, and other "fake entries"
• If the log format uses JSON or key-value pairs, check whether escaping defects cause structural corruption

Required output:

• Which fields are controllable (GET/POST/Headers/Body/Cookie)
• Injection entry point (log message concatenation point)
• Whether filtering/normalization exists (especially handling of newlines and control characters)

4) Defects in the Logging and Alerting Chain (Monitoring & Alert Gaps)

Identify monitoring-chain gaps (based on what the code/configuration can prove):

• Critical security events are only logged at debug/info and do not enter an alertable channel
• Missing log levels and alert rules (for example, production has disabled the security alert channel)
• Error handling swallows exceptions, causing critical events not to be written

Required output:

• The log level/channel/handler configuration evidence you located in the source code
• How this evidence causes alerts not to fire or critical evidence to be unavailable

Identification logic (required)

Log write Sink (code)

The following log-related APIs must be identified (replace with the project's actual ones):

• PHP：error_log({value})
• System:syslog({value})
• PSR-3/framework:->info({value}) ->warning({value}) ->error({value}) ->critical({value}) ->debug({value})
• Laravel/Symfony/custom wrapper:Log::{value}({value})、logger->{value} or the project's own logger wrapper
• Monolog：Monolog\Logger and handler/channel-related configuration

Message construction and controllability (data flow)

For each log write point, at least one chain must be traced:

• Source (request field/user input/source of sensitive token) -> intermediate variable processing (concatenation, formatting, json_encode, template string) -> Sink (the message parameter finally written to the log)

And output:

• Controllable field name (or JSON path)
• Whether there is sanitization before entering the log (newline/control characters/sensitive field masking)
• Whether conditional branches cause "only certain branches write logs" (log write bypass)

PoC (required: observable verification framework)

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

• Use a real route to trigger log writing, and explain the expected field/format changes in the log
• Use a crafted payload to inject newline/control characters, and explain that the expected log will be split into lines or contain forged fragments

PoC output requirements:

• Must include a real route (prefer from routes_{timestamp}.md replacement; standalone file persistence see route_mapping/routes_{timestamp}.md, conventions see shared/IO_PATH_CONVENTION.md）
• Must write the request headers and body/parameters used for triggering (including at least one controllable field that will enter the log message)
• Must explain what you need to observe in the log file/console/system log (for example, whether a field appears as-is)

Report output

Output to:

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

Vulnerability entry template (mandatory)

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

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

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

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

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

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

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

{Payload}

(Log phenomenon you need to observe after the PoC: {clearly write the expected log content/format changes/whether newline splitting occurs})

Recommended fix

• Secure coding key points: sensitive field masking, control character sanitization, structured logging, log level and alert mapping
• Code search statement: use rg to locate all code blocks related to log writing and message construction

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