php-auth-audit

PHP authentication mechanism audit (Auth Audit)

Analyzes PHP web project source code, identifies authentication and authorization chains, determines the authentication status of each route, and detects authentication bypass/privilege escalation/IDOR risks.

CRITICAL: Full analysis (mandatory)

• Must process all routes appearing in php-route-mapper must identify the authentication chain: Session/JWT/middleware/custom validation functions
• Must identify the authentication chain: Session/JWT/middleware/custom validation functions
• Must output route-auth mapping table (no omissions)
• For all suspicious points, provide: location evidence + data flow chain + exploitability analysis + verification PoC + remediation recommendations

Run mode (mandatory: aligned with pipeline stages)

This skill supports two modes to address the issue of "being unable to reference EVID_* before a trace has been generated":

1. STATIC_MAPPING(Recommended for pipeline stage 1)
   • Only generate auth_mapping_{timestamp}.md(and optionally auth_README_{timestamp}.md）
   • Allow missing php-route-tracer EVID_* evidence point references of EVID_* evidence point references
   • Must provide: authentication status grading (✅/⚠️/❌/❓) and P0/P1 bucketing rationale (no PoC required)

1. TRACE_AUDIT(Recommended for pipeline stage 4, when trace exists)
   • Generate the complete auth_audit_report_{timestamp}.md, and mandatorily cite each EVID_* evidence point
   • PoC/remediation recommendations must be complete

Vulnerability grading

See:shared/SEVERITY_RATING.md

Input dependencies

Recommended input (consistent with shared/IO_PATH_CONVENTION.md ; when merging pipelines, read the equivalent section in the overall report):

• routes_{timestamp}.md(when stored independently, usually route_mapping/routes_{timestamp}.md）
• params_{timestamp}.md(when stored independently, usually route_mapping/params_{timestamp}.md）

Optional:

• source_path

Identify authentication implementation (mandatory)

Identify by framework:

• Laravel：
  • middleware('auth'|'can'|'role:')
  • Auth::check()/Auth::user()
  • Policies/Gates：Gate::allows、->can({value})
  • Route protection:Route::middleware([{value}])->group({value})
• Symfony：
  • security.yaml / access_control
  • denyAccessUnlessGranted、isGranted
  • voter/policy
• Native PHP:
  • session_start + $_SESSION determination
  • if (!isset($_SESSION['user']))/requireLogin()
  • Custom functions:checkAuth/authorize/hasRole/isAdmin

Route-auth mapping (mandatory)

For each route, output the following status:

• ✅ Public: explicitly allowed, no authentication checks
• ✅ Protected: complete authentication/authorization checks exist
• ⚠️ Authentication only: only verifies login state, no role/resource-level authorization
• ❌ No authentication: no authentication chain is hit
• ❓ Uncertain: dynamic permissions/complex custom logic make it hard to judge (evidence points must still be written)

And output the risk type:AUTH, including:

• Authentication bypass (login state check is bypassed)
• Authorization bypass/privilege escalation (role check missing or incorrect)
• IDOR (object access lacks ownership/belonging check)

Suspicious pattern detection (mandatory, provide evidence chain)

1) Path/URI matching leads to authentication bypass

Common root causes in PHP:

• Using raw $_SERVER['REQUEST_URI'] or parse_url results for whitelist matching, but the path is not normalized
• Encoding/case/repeated slashes/trailing character differences cause matching failure (the actual route enters a protected handler)

Must output:

• Whitelist check location and code snippet
• Bypass request (PoC) and evidence of the hit handler

2) Only verifies login state, missing role/resource authorization

Must output:

• The route's "authentication check" location
• The "authorization check missing" location (e.g., only checks user!=null then directly performs sensitive operations)

3) IDOR/privilege escalation

Must output:

• Where the sensitive object id comes from (GET/POST/URL)
• Whether the "ownership check" used for query/update exists (whether WHERE includes user_id/owner_id)
• The reason it is unverified and its reachability

Report output (by run mode)

Output to:

{output_path}/auth_audit/
├── auth_audit_report_{timestamp}.md
├── auth_mapping_{timestamp}.md
└── auth_README_{timestamp}.md

Mandatory rules:

• STATIC_MAPPING: must generate auth_mapping_{timestamp}.md；auth_audit_report_{timestamp}.md may be omitted or generated as an empty shell (and annotated: bucket mapping only, no trace evidence)
• TRACE_AUDIT: must generate the complete three files, and require all trace evidence points to be present

File 1: Main report auth_audit_report_{timestamp}.md

Includes:

• Authentication framework identification (including version/implementation evidence)
• Authentication architecture overview (middleware/function/handler)
• Risk statistics
• The complete vulnerability structure of each risk (number/severity/data flow/PoC/fix)

File 2: Mapping table auth_mapping_{timestamp}.md

List only routes and authentication status, required roles/conditions (do not include detailed vulnerability analysis). But a bucket field must be added (used for pipeline stage 3 route selection):

• p_bucket：P0 or P1
  • P0: ❌ No authentication
  • P1: ⚠️ Authentication only, or an authorization bypass/privilege escalation/IDOR risk is detected (even if the authentication status shows "authentication only", you must explain in p1_reason why it enters P1)
• p1_reason: a brief static basis (e.g., "login state only, missing hasRole/authorize or missing owner_id check")

File 3: Documentation auth_README_{timestamp}.md

Explain only the methodology, tools, and verification guide, without including specific vulnerability details.

PoC verification template (mandatory)

Must distinguish at least the following scenarios:

• Unauthenticated access (no cookie/session/JWT)
• Normal user access (normal account cookie/JWT)
• Admin/high-privilege control (if applicable)

The PoC must be an executable HTTP request code block, and the route path must use the real route rules.

Evidence references (mandatory by run mode)

• STATIC_MAPPING: trace EVID_* evidence points are not mandatory (only output the authentication classification and P0/P1 bucket basis).
• TRACE_AUDIT: each suspected authentication risk must cite the evidence from the trace output item by item (the status may be marked as pending verification, but the evidence reference must exist):

1. EVID_AUTH_PATH_PROTECTED_MATCH: evidence of the route path matching into the protected handler (corresponding to the trace's branch path evidence)
2. EVID_AUTH_TOKEN_DECODE_JUDGMENT: evidence of how the login state/token decoding result is judged (corresponding to session/JWT reading and conditional branches in the trace)
3. EVID_AUTH_PERMISSION_CHECK_EXEC: execution evidence of the permission judgment function or conditional statement (e.g., hasRole/authorize) (trace sink location or branch evidence)
4. EVID_AUTH_IDOR_OWNERSHIP_CONDITION: evidence of whether the IDOR ownership check (WHERE/condition) includes owner_id/user_id (the final query condition or state update statement in the trace)

Handling of missing tracer evidence (mandatory)

• STATIC_MAPPING: not applicable (the bucket basis is based on static code evidence).
• TRACE_AUDIT: if the trace contract validation fails or any one of key evidence points 1~4 cannot be located: the risk can only be marked as ⚠️待验证, must not give ✅已确认可利用 or the conclusion "confirmed bypassable".