Code Audit — PHP XSS

1. XSS Vulnerability Basics

Cross-Site Scripting (XSS) is an attack where malicious scripts are injected into a trusted website. When other users visit the site, the script executes in their browser, enabling cookie theft, session hijacking, phishing, and more.

XSS is categorized by storage location:

• Reflected XSS: the malicious script resides in request parameters; the server echoes it directly without storing it.
• Stored XSS: the malicious script is persisted in a database or file and triggers on every page visit.
• DOM-based XSS: a purely client-side vulnerability that never touches the server. PHP audits typically focus only on the first two types.

2. Common XSS Trigger Points in PHP (Output Contexts)

When PHP code outputs data into different positions within HTML, each context requires its own escaping approach. Missing any one of them can lead to XSS.

3. Code Audit Methodology: Input Tracing and Output Inspection

The core approach to auditing XSS is "data-flow tracing":

1. Identify all user input sources: $_GET, $_POST, $_COOKIE, $_REQUEST, $_SERVER (e.g., HTTP_USER_AGENT), file upload names, data read from databases, etc.
2. Trace the data flow: starting from input points, follow the data through various function calls until it reaches an output point.
3. Check whether proper context-aware escaping is applied at the output point.

The four-step audit method:

• STEP 1: locate all output functions (echo, print, print_r, var_dump, printf, die, exit, etc.).
• STEP 2: check whether the output contains user-controllable data (directly or indirectly).
• STEP 3: confirm whether appropriate escaping functions were applied before output (htmlspecialchars, htmlentities, filter_var, custom filters).
• STEP 4: determine whether the escaping function was used correctly for the current output context (are the parameters set properly?).

4. PHP Security Function Analysis

htmlspecialchars()

• Purpose: converts special characters into HTML entities (&, ", ', <, >).
• DefaultThe default value is ENT_COMPAT, which escapes double quotes only — single quotes are left unescaped. ENT_COMPAT(escapes double quotes only; single quotes are not escaped).
• Important parameters:
• ENT_QUOTES: escapes both single and double quotes (recommended).
• ENT_HTML5: specifies the document type.
• ENT_SUBSTITUTE: substitutes invalid characters.
• Limitation: only effective for HTML body content; unsuitable for attribute, JavaScript, or CSS contexts (additional handling is required).

htmlentities()

• Converts all available characters to entities. The default character set may cause issues (such as garbled Chinese text) and it carries significant performance overhead. Generally not recommended for XSS prevention unless specific requirements exist.

strip_tags()

• Purpose: strips HTML and PHP tags.
• Limitations: cannot prevent JavaScript events within attributes (e.g., onclick), and bypass techniques exist (e.g., <svg onload=alert(1)>). Not recommended as a primary defense measure.

filter_var() combined with FILTER_SANITIZE_STRING

• Deprecated (PHP 8.1+) and not context-aware.

Custom filtering (regex, blacklists) is extremely dangerous—bypasses are almost always possible.

5. Classic Techniques for Bypassing Security Functions

Even when htmlspecialchars is used, improper parameter configuration or incorrect context can still leave it exploitable.

• Unescaped single quotes (default ENT_COMPAT):

If $name = "' onclick='alert(1)", the output becomes <input value='' onclick='alert(1)'>, and the attack succeeds.

• In a JavaScript string context:

If $name = "alert(1)\";//", the output becomes var name = "alert(1)\";//";, which prematurely closes the string and injects code.

• Failing to double-encode ENT_NOQUOTES in an HTML attribute & in an HTML attribute:

If $page = "javascript:alert(1)", although : and alert will not be escaped, the href attribute supports the javascript: protocol and can execute directly.

• Exploiting browser error tolerance: e.g., <img src=x onerror=alert(1)>, strip_tags may retain onerror.
• Character encoding bypass: using entity encoding such as alert. If output in an HTML attribute is not decoded correctly, the browser may still parse it.

6. Escaping Requirements for Different Contexts

7. Stored XSS Audit Focus

Stored XSS data comes from the database, so during an audit you must trace not only request input but also output after reading from the database.

Common scenarios:

• User comments, posts, message boards.
• User profiles (nicknames, signatures).
• System configuration items (such as site title) that are editable but not escaped.

Audit tips:

• Look for INSERT/UPDATE operations and check whether the data was filtered (it may only have SQL injection protection, with XSS overlooked).
• Look for places where SELECT results are output to templates and confirm whether escaping is applied.

8. Audit Tools and Auxiliary Techniques

• Static analysis tools: RIPS, Psalm, PHPStan (custom rules can be defined).
• Dynamic debugging: Xdebug paired with browser developer tools to observe output.
• Automated fuzz testing: Burp Suite's Intruder for sending XSS payloads in bulk.
• Manual audit keywordsManual audit keywords include: echo, print, $_GET, $_POST, htmlspecialchars, strip_tags, addslashes, htmlentities.

9. Complete Audit Case Study (Step-by-Step Analysis)

Suppose we have the following PHP code for a blog system:

Audit steps:

1. Identify the input point: $_GET['id'], used to query an article.
2. Trace the data flow: $id → getArticleById() → returns the $article array → output each field.
3. Inspect the output points:

• $article['title'] is output in the HTML body (inside <h1>) — requires htmlspecialchars.
• $article['content'] is output inside div.content — requires htmlspecialchars, otherwise a user could submit content containing <script> tags.
• $article['author'] and $article['time'] have the same issue.
• Most dangerous: onclick="addFavorite(<?php echo $article['id']; ?>)" — unquoted and directly output as a number. If id comes from the database and has been tampered with as 1); alert(1)//, it will lead to XSS.

4. Check the defenses: no escaping functions exist anywhere in the code.
5. Conclusion: there is reflected XSS (via the id parameter, which may affect query results, though output is mainly in content), stored XSS (article content), and JavaScript context injection.

Remediation suggestions:

• Apply htmlspecialchars($val, ENT_QUOTES, 'UTF-8') to all output.
• For JavaScript contexts, use json_encode($article['id']) to ensure type safety: onclick="addFavorite(<?= json_encode($article['id']) ?>)".

10. Remediation Plan and Secure Coding Standards

• Unified output encoding function: wrap a h($str) function that internally calls htmlspecialchars and use it in all templates.
• Use a template engine (such as Twig) with auto-escaping enabled to greatly reduce oversights.
• Disable strip_tags and switch to whitelist-based filtering (such as HTMLPurifier) if rich text is genuinely needed.
• Set the correct character set: header('Content-Type: text/html; charset=utf-8'); to prevent encoding bypasses.
• CSP (Content Security Policy) as a defense-in-depth measure to restrict script sources.
• Regular code reviews + automated scanning (such as OWASP ZAP).