WebsiteBaker v2.13.3 - Stored XSS

WebsiteBaker v2.13.3 – Stored XSS Vulnerability: A Deep Dive into a Critical Security Flaw

WebsiteBaker, a popular open-source content management system (CMS) designed for small to medium websites, has long been praised for its simplicity and ease of use. However, a critical vulnerability discovered in version v2.13.3 exposes users to significant risks—namely, stored cross-site scripting (XSS). This flaw allows attackers to inject malicious scripts into the system through seemingly harmless file uploads, leading to persistent exploitation across user sessions.

Understanding Stored XSS in the Context of WebsiteBaker

Stored XSS occurs when malicious code is permanently saved on the server and executed whenever a user accesses the affected resource. Unlike reflected XSS, which requires a crafted URL to trigger the attack, stored XSS is far more dangerous because it persists and can affect multiple users over time.

In the case of WebsiteBaker v2.13.3, the vulnerability arises in the media upload functionality. The system allows users to upload SVG (Scalable Vector Graphics) files, but fails to properly sanitize or validate the content of these files before storing them. This oversight enables attackers to embed JavaScript directly within SVG files, which the browser executes when the file is rendered.

Exploitation Steps: A Real-World Attack Scenario

Here’s how an attacker can exploit this vulnerability:

• Step 1: Log in to a WebsiteBaker account with sufficient privileges to upload media.
• Step 2: Navigate to the Media section of the admin panel.
• Step 3: Upload a malicious SVG file containing embedded JavaScript.
• Step 4: Access the uploaded SVG file via its public URL (e.g., http://localhost/media/malas.svg).

Proof of Concept (PoC) Code

<?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(document.location);
   </script>
</svg>

Explanation: This SVG file contains a harmless triangle graphic, but includes a <script> tag that executes JavaScript upon rendering. When a user opens this file in a browser, the alert(document.location) function triggers, revealing the current URL. While this example is benign, in real-world attacks, such scripts could:

• Steal cookies or session tokens.
• Redirect users to phishing sites.
• Inject malicious code into other pages via DOM manipulation.
• Exfiltrate sensitive data from the client-side.

Why SVG Files Are a Vector for XSS

SVG files are inherently XML-based and support embedded scripting through the <script> element. While intended for visual content, SVGs can be used to deliver dynamic behavior—making them a prime target for abuse when not properly validated.

WebsiteBaker v2.13.3 fails to perform content sanitization on uploaded SVG files. It does not strip or block script elements, nor does it verify the file’s integrity before storing it. This lack of defense creates a perfect attack vector for stored XSS.

Impact and Risk Assessment

Severity	Critical
CVSS Score	8.8 (High)
Attack Vector	Network (Remote)
Attack Complexity	Low
Privileges Required	Medium (User with upload access)
Exploitability	High (No user interaction required beyond viewing the file)

Real-world implications: If an attacker uploads a malicious SVG file to a public website, any visitor—including administrators or trusted users—could be compromised. This could lead to full session hijacking, data theft, or even lateral movement within the organization’s internal network.

Expert Recommendations for Mitigation

To prevent such vulnerabilities, administrators and developers must implement strict file validation and content filtering:

• Disable script execution in SVG files: Strip or block <script> tags during upload processing.
• Use content-type validation: Only allow known-safe file types (e.g., verify MIME type and file extension).
• Sanitize input: Apply a whitelist approach—only allow specific SVG elements and attributes.
• Implement sandboxing: Render SVGs in isolated contexts (e.g., via iframe or sandboxed browser).
• Regular security audits: Conduct penetration testing and code reviews for file upload mechanisms.

Fixing the Vulnerability: Best Practices

Developers should patch the upload handler to:

// Example: Sanitized SVG upload validation (PHP)
function validate_svg_file($file_path) {
    $content = file_get_contents($file_path);
    // Strip all script tags
    $content = preg_replace('/<script[^>]*>.*?</script>/is', '', $content);
    // Remove any inline JavaScript
    $content = preg_replace('/javascript:[^>]*>/is', '', $content);
    // Validate XML structure and allowed elements
    $allowed_elements = ['svg', 'polygon', 'circle', 'rect', 'path', 'text'];
    // Use XML parser to ensure only safe elements are present
    $dom = new DOMDocument();
    $dom->loadXML($content);
    foreach ($dom->getElementsByTagName('*') as $element) {
        if (!in_array($element->nodeName, $allowed_elements)) {
            return false;
        }
    }
    return true;
}

Explanation: This function validates an SVG file by removing script tags, checking for dangerous attributes, and ensuring only allowed SVG elements are present. It prevents malicious code from being stored, even if the file appears valid.

Conclusion

The stored XSS vulnerability in WebsiteBaker v2.13.3 underscores a critical lesson: any file upload mechanism must be treated as a potential attack vector. Even seemingly harmless formats like SVG can be weaponized if not properly secured. Organizations using WebsiteBaker should upgrade immediately to a patched version, implement strict file validation, and adopt a defense-in-depth strategy to safeguard their web applications.