Perch v3.2 - Persistent Cross Site Scripting (XSS)

Perch v3.2 Persistent Cross Site Scripting (XSS) Vulnerability: A Deep Dive into a Critical Security Flaw

Perch, a lightweight content management system (CMS) developed by Grabaperch, has long been praised for its simplicity and ease of use. However, a critical security flaw discovered in version v3.2 exposes users to a severe threat: stored cross-site scripting (XSS). This vulnerability allows attackers to inject malicious scripts into the application through the asset upload functionality, which persistently execute whenever the affected file is viewed — making it one of the most dangerous types of XSS attacks.

Understanding the Vulnerability: Stored XSS in Perch v3.2

Stored XSS occurs when malicious code is saved on the server and subsequently executed every time a user accesses the affected resource. Unlike reflected XSS, which requires a user to click a malicious link, stored XSS is persistent, meaning it can affect multiple users over time without further interaction.

According to the exploit report by Dinesh Mohanty, the vulnerability exists in the file upload functionality within the Assets section of Perch v3.2. Specifically, when users upload SVG (Scalable Vector Graphics) files, the system fails to sanitize or validate the content, allowing embedded JavaScript code to be executed directly in the browser.

Exploitation Steps: How the Attack Works

Here’s a step-by-step breakdown of how an attacker can exploit this vulnerability:

• Login to the Perch application with valid credentials.
• Navigate to Assets via the left-side menu: http://URL/perch/core/apps/assets/.
• Click on Add Assets and fill out required fields (note: not all input fields are vulnerable — only those handling file uploads).
• Create an SVG file named xss.svg with the following malicious content:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
 <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
 <script type="text/javascript">
    alert("XSS");
  </script>
</svg>

This SVG file contains a script tag with a simple JavaScript alert() function. While harmless in isolation, it demonstrates the core issue: untrusted content is rendered without sanitization.

• Upload the xss.svg file via the file upload section.
• After submission, the file is stored in the /perch/resources/ directory.
• Access the file directly: http://URL/perch/resources/xss.svg.
• Upon loading, the browser executes the embedded script — triggering an alert("XSS") popup.

This proves that the script was stored and executed without any user interaction beyond viewing the file — a hallmark of stored XSS.

Why SVG Files Are a Vector for XSS

SVG files are inherently capable of embedding JavaScript, thanks to their support for <script> elements. While intended for graphical rendering, this feature is frequently abused in security exploits because:

• SVGs are often treated as "safe" media files by developers.
• Many CMS platforms do not apply strict validation to SVG content.
• They are commonly uploaded via user-facing interfaces, making them ideal for malicious payloads.

Perch v3.2 fails to detect or filter out <script> tags in SVG files, allowing attackers to bypass traditional input validation mechanisms.

Real-World Implications and Attack Scenarios

While the example uses a harmless alert(), real-world attacks could involve:

• Stealing session cookies via document.cookie.
• Redirecting users to phishing sites.
• Injecting keyloggers or malware via eval() or fetch() calls.
• Exploiting other vulnerabilities in the application via DOM manipulation.

Given that Perch is used in both small business and enterprise environments, this vulnerability could lead to:

• Account compromise for authenticated users.
• Privilege escalation via session hijacking.
• Widespread data exfiltration across multiple user sessions.

Security Best Practices and Mitigation

Developers and administrators must implement strict file validation to prevent such attacks. Here are key recommendations:

• Sanitize SVG Content: Strip or block <script>, <iframe>, and <object> elements from SVG files before storage.
• Use Content Security Policy (CSP): Implement a strict CSP header that blocks inline scripts and restricts external script sources.
• Validate File Types: Use MIME-type checks and file signature verification to ensure uploaded files are legitimate SVGs.
• Implement a Preview Sandbox: Render SVGs in isolated environments (e.g., iframe) to prevent script execution.
• Disable JavaScript in SVGs: Configure the server to ignore or remove script tags during file processing.

Corrected Code Example: Safe SVG Handling

Here’s an example of how a secure SVG processing function could be implemented:

function sanitize_svg($svg_content) {
    // Remove script tags and any dangerous elements
    $svg_content = preg_replace('/<script[^>]*>.*?<\/script>/is', '', $svg_content);
    $svg_content = preg_replace('/<iframe[^>]*>.*?<\/iframe>/is', '', $svg_content);
    $svg_content = preg_replace('/<object[^>]*>.*?<\/object>/is', '', $svg_content);
    $svg_content = preg_replace('/<embed[^>]*>.*?<\/embed>/is', '', $svg_content);

    // Ensure no inline JavaScript or event handlers
    $svg_content = preg_replace('/on[^=]*="[^"]*"/', '', $svg_content);

    return $svg_content;
}

This function removes all potentially dangerous elements from SVG content before storage. It ensures that even if a malicious file is uploaded, the harmful code is stripped out before rendering.

Vendor Response and CVE Status

As of July 23, 2023, the vendor Grabaperch has been notified, and a CVE request has been submitted. The absence of a CVE identifier at this time indicates the vulnerability is still under review. However, users should treat this as a critical risk until patched.

Recommendations for Users

For administrators using Perch v3.2:

• Immediately disable SVG file uploads if not strictly necessary.
• Apply patching or upgrade to the latest version (if available).
• Monitor logs for suspicious file uploads.
• Implement web application firewalls (WAF) to detect and block known XSS patterns.

Security is not a one-time fix — it requires continuous vigilance. This vulnerability underscores the importance of validating all user-generated content, regardless of file type.

Conclusion: Lessons from Perch v3.2

Perch v3.2’s stored XSS flaw serves as a stark reminder: even seemingly harmless file types like SVG can be weaponized. The lack of input validation in file upload systems is a common oversight that leads to severe consequences.

Developers must adopt a defense-in-depth strategy: never trust user input, validate file types rigorously, and sanitize content before rendering