Analyze the authentication session-related security settings and implementation logic in PHP project source code, focusing on detecting:
- session fixation
- missing cookie flags (HttpOnly/Secure/SameSite)
- JWT validation flaws (signature algorithm confusion, missing exp/iss/aud validation, weak keys)
- remember-me/persistent login weaknesses (if present)
Severity and numbering
- See:
shared/SEVERITY_RATING.md - Vulnerability ID:
{C/H/M/L}-SESS-{序号}
Mandatory checks (required)
- Session initialization:
- Whether after login
session_regenerate_id - Whether reasonable timeout and cookie parameters are set
- Whether after login
- Cookie flags:
HttpOnly、Secure、SameSiteWhether explicitly set
- JWT:
- Whether the algorithm used by decode/verify is fixed
- Whether it validates
exp/nbf/iss/aud - Whether secret/public key is hardcoded or read insecurely
- Logout/invalidation:
- Whether logout truly clears the session and token
PoC requirements (required)
- For session fixation: provide the request sequence (fix session id before login -> verify session change after login)
- For cookie flags: explain the browser-side visible differences and harm (and provide an example HTTP response header)
- For JWT: provide a request PoC framework for "missing signature algorithm/claim validation" (must explain how the payload is constructed)
Evidence citation (required: from php-route-tracer)
Each suspected session and Cookie security risk must cite, item by item, from the trace output ## 9) Sink Evidence Type Checklist the SESS linecorresponding evidence points (the status is allowed to be pending verification, but the evidence citation must exist):
EVID_SESS_SESSION_INIT_REGEN: whether after loginsession_regenerate_idand other session fixation protection evidenceEVID_SESS_COOKIE_FLAGS: evidence of Cookie flags (HttpOnly/Secure/SameSite) settingsEVID_SESS_JWT_VERIFY_CLAIMS: evidence of fixed JWT signature algorithm and validation of claims such as exp/nbf/iss/audEVID_SESS_LOGOUT_CLEAR: evidence of whether logout truly clears the session and token
Handling of missing tracer evidence (required)
- If the trace contract validation fails or any of the above key evidence points 1~4 is missing: the risk can only be marked as
⚠️待验证, and no assertion of "confirmed exploitable" may be given.
Report output
{output_path}/vuln_audit/sess_{timestamp}.md
Entry template (required)
Must include: location evidence + data flow chain (token/session -> validation -> authorization) + exploitable preconditions + PoC + remediation recommendations + rg search statement.