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

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

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

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

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

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

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

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

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)

Log Writing Sink (Code)

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)

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 (Mandatory: Observable Verification Framework)

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 to:

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

Vulnerability Entry Template (Mandatory)

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

markdown

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

| 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
- 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)

#### Data Flow Chain (Source -> Transform -> Sink)
(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}

#### Verification PoC (Mandatory, Observable)
```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

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


## Output Completeness Check (Mandatory)
- [ ] 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)

php-logging-audit

NPX Install

Tags

SKILL.md Content (Chinese)

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

Rating and Numbering

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

1) Audit Gap

2) Sensitive Data in Logs

3) Log Injection / Forging

4) Monitoring & Alert Gaps

Identification Logic (Mandatory)

Log Writing Sink (Code)

Message Construction and Controllability (Data Flow)

PoC (Mandatory: Observable Verification Framework)

Report Output

Vulnerability Entry Template (Mandatory)

Remediation Recommendations