php-frontend-audit

PHP front-end interaction vulnerability source code audit

This skill focuses on determining at the source code level whether a "front-end security vulnerability is valid"; the core is verifying whether user-controllable data output in the HTTP response is safe. Runtime exploitation techniques such as crafting payloads and bypassing WAFs fall under the corresponding black-box exploit skill scope.

In-depth reference

• Dangerous patterns / safe pattern code comparison / EVID evidence examples for 5 categories of front-end vulnerabilities → references/frontend-patterns.md

---

5 categories of front-end vulnerabilities quick reference table

Type	Typical Sink	Trigger condition	Severity
XSS (reflected/stored/DOM)	echo, print, template output {!! !!}	User input output to HTML context without escaping	High-Critical
CSRF	State-changing form/API	Missing Token validation and no SameSite protection	Medium-High
Open redirect	header("Location:"), framework redirect()	Redirect target URL fully user-controllable	Medium
CRLF injection	header(), setcookie()	User input contains \r\n enters HTTP response headers	Medium-High
Session security	session_start(), setcookie()	session fixation/missing Cookie attributes	Medium-High

XSS audit key points

• Output context determines escaping requirements: HTML body, attributes, JavaScript strings, and URLs each require different escaping strategies; a single htmlspecialchars cannot cover all scenarios
• htmlspecialchars check: confirm that ENT_QUOTES flag is used (default ENT_COMPAT does not escape single quotes) and the correct encoding parameter ('UTF-8'）
• Template engine auto-escaping: Blade {{ }} auto-escapes but {!! !!} does not escape; Twig {{ }} auto-escapes but |raw filter skips; Smarty depends on $escape_html configuration
• Stored vs reflected: stored requires tracing across the storage boundary—whether data is filtered when stored is not important; the key is whether it is escaped on output
• DOM XSS: PHP backend outputs JSON to <script> tag or HTML data attribute; front-end JS retrieves it and writes it to the DOM (innerHTML/document.write）

CSRF audit key points

• State-changing operation identification: all operations that modify data in POST/PUT/DELETE requests should have Token validation
• Framework middleware exceptions: Laravel VerifyCsrfToken of $except array, ThinkPHP's token_on configuration—excluded routes are high-risk targets
• SameSite attribute: SameSite=Lax can defend against most CSRF (but not GET-based),None no protection, default value varies by browser
• Custom Token implementation: check whether the Token is bound to the Session, whether it is consumed once, and whether it has a time limit

Open redirect audit key points

• Controllable header Location: header("Location: " . $_GET['url']) is a classic pattern, and also includes the framework's redirect($url)
• parse_url bypass: //evil.com(protocol-relative URL),///evil.com、\evil.com(IE compatible),javascript: pseudo-protocol can all bypass simple validation
• Security whitelist: The correct implementation is to parse the host and then compare it against the list of allowed domains, rather than regex matching or prefix checking (example.com.evil.com bypass prefix)

CRLF audit points

• header() + user input: header("X-Custom: " . $input) contains $input containing \r\n can inject additional response headers
• PHP version differences: PHP 7.0+ header() already detects \r\n and throws a warning (but setcookie() protection was only completed in PHP 8.x)
• Exploitation methods: Inject Set-Cookie header to achieve session fixation, inject a blank line and then write the body to achieve XSS

Session security audit points

• session_regenerate_id timing: This function should be called after successful login to prevent session fixation. Parameter true deletes the old session file
• Cookie attributes: session.cookie_httponly=1(prevents JS reading),session.cookie_secure=1(HTTPS only),session.cookie_samesite=Lax
• Custom Session Handler: When implementing SessionHandlerInterface ,read()/write() is there an injection risk (such as SQL concatenation when storing in a DB)

Detection checklist

• All frontend-type EVID_* evidence points have been reviewed one by one
• The context type of echo/print output points has been annotated, and the escaping method matches the context
• Whether the template engine's automatic escaping has been disabled has been checked
• CSRF Token verification for state-changing routes has been confirmed, and exception routes have been marked
• The source of the target parameters of header() and redirect() has been traced
• CRLF injection has been cross-confirmed against PHP versions and affected functions
• Session configuration (php.ini / code ini_set) has been audited
• The four Cookie attributes (httponly/secure/samesite/path) have been checked item by item
• Severity scoring uses a unified formula, consistent with the pipeline