Full Report
Cross site scripting (XSS) is a super common web vulnerability. If a user can include HTML into the page, then you can commonly add your own JavaScript to perform malicious actions. Sometimes, some HTML should be allowed for styling. Because of this, HTML sanitizers are super important for preventing security issues in these cases. These sanitizers work by parsing the HTML input to create a structured DOM tree object. Then, parsing this DOM to ensure that nothing defined as malicious exists. This HTML sanitizing should be done on the client side in order to prevent parser differential issues. In reality, it's done on the server-side quite a bit. Sonar source has found a lot of sanitizer bypasses in the past. They noticed that a group of them worked on almost all of them written in PHP. All of the bypasses were relating to comments, math, RCdata and RAWData. All of these are new HTML 5 features! The built in PHP HTML parser uses an out-of-date HTML 4 specification from libxml2. If the parser used for cleaning was the same as the execution (being in the browser), this issue wouldn't have existed. It's just a standard though, how hard can this really be? HTML is a constantly evolving language. New elements, attributes and features are regularly introduced. Different users are also running different versions of browsers, which causing some complications here. The author claims that the parser configuration can make a big difference as well. If scripting is enabled or not can determine how some elements are parsed. Another issue surrounds parsing weird HTML. If something goes through a parser multiple times in a loop, the output may be different in the two cases. Additionally, mutation XSS can be used too. The issue around PHP was never fixed. Instead, this big PHP library now has a big red warning label that it shouldn't be used for sanitizing because it doesn't support HTML5 very well. Overall, a good post around a bad practice and an interesting vulnerability in the improper usage of a library.
Analysis Summary
# Vulnerability: PHP Server-Side HTML Sanitizer Bypass via Parser Differential
## CVE Details
* **CVE ID:** Not specifically assigned to a single vulnerability (this describes a fundamental architectural flaw and multiple bypasses found by Sonar).
* **CVSS Score:** N/A (High Severity impact, typically 7.5 - 8.8 for XSS)
* **CWE:** CWE-79 (Cross-site Scripting), CWE-436 (Interpretation Conflict)
## Affected Systems
* **Products:** Various PHP HTML Sanitization libraries and the PHP built-in HTML parser.
* **Versions:** Versions relying on the native PHP `libxml2` DOM parser.
* **Configurations:** Server-side HTML sanitization where the parser uses the legacy HTML4 specification while the client (browser) uses HTML5.
## Vulnerability Description
The flaw stems from a **Parser Differential** between server-side PHP sanitizers and modern web browsers. The built-in PHP HTML parser utilizes an outdated HTML4 specification from `libxml2`. Modern browsers utilize the HTML5 specification, which introduced new elements and parsing rules for `Comments`, `Math` (MathML), `RCData`, and `RawData`.
Because the PHP parser does not recognize these HTML5 constructs, it may misinterpret malicious payloads as inert text or comments. However, when the "sanitized" output is rendered in a browser, the browser's HTML5 parser interprets those same segments as executable JavaScript. This discrepancy allows attackers to smuggle XSS payloads past the sanitizer.
## Exploitation
* **Status:** PoC available (demonstrated by SonarSource research).
* **Complexity:** Medium (Requires knowledge of HTML5 parsing quirks and Mutation XSS).
* **Attack Vector:** Network (Web-based input).
## Impact
* **Confidentiality:** High (Session hijacking, cookie theft).
* **Integrity:** High (Unauthorized actions performed on behalf of the user, DOM manipulation).
* **Availability:** Low (Possible UI defacement).
## Remediation
### Patches
* **No Direct Patch:** The issue in the core PHP `libxml2` implementation remains unfixed regarding full HTML5 support.
* **Library Updates:** Major PHP sanitization libraries (such as HTML Purifier) have added documentation or "red warning labels" advising against use for HTML5 content.
### Workarounds
* **Client-Side Sanitization:** Shift HTML sanitization to the client side using the **Browser's native Sanitizer API** or libraries like **DOMPurify**. This ensures the parser used for cleaning matches the parser used for execution.
* **Context-Aware Output Encoding:** Ensure all user-supplied data is correctly encoded for the specific UI context.
* **Content Security Policy (CSP):** Implement a strict CSP to prevent the execution of unauthorized inline scripts and untrusted resources.
## Detection
* **Indicators of Compromise:** Presence of MathML (`<math>`), SVG, or complex nested comments in stored user data that appear to "break out" of standard HTML tags.
* **Detection Methods:**
* Manual audit of PHP codebases for usage of `DOMDocument::loadHTML`.
* Security scanners that specifically test for **Mutation XSS (mXSS)** and parser differential payloads.
## References
* SonarSource Research: hxxps[://]www[.]sonarsource[.]com/blog/
* OWASP XSS Prevention Manual: hxxps[://]cheatsheetseries[.]owasp[.]org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet[.]html
* PHP libxml documentation: hxxps[://]www[.]php[.]net/manual/en/book[.]libxml[.]php