Petrol Pump Management Software v.1.0 - Stored Cross Site Scripting via SVG file

Petrol Pump Management Software v1.0 — Stored Cross‑Site Scripting via SVG Upload (CVE-2024-27744)

This article analyzes CVE-2024-27744, a stored Cross‑Site Scripting (XSS) vulnerability discovered in Petrol Pump Management Software v1.0. It explains why SVG uploads are risky, the technical root cause, safe methods to detect and remediate the issue, and practical hardening guidance and sample fixes for web applications — with an emphasis on defensive controls.

Executive summary

A stored XSS vulnerability exists where user-supplied SVG images are accepted and later served without removing executable content (for example, inline <script> tags or JavaScript attributes). When an administrator or other user views the file, the browser can execute embedded scripts, allowing arbitrary JavaScript execution in the victim's browser context. The vulnerability is tracked as CVE-2024-27744.

Why SVG files are a unique risk

• SVG is XML-based and supports inline scripts, event attributes (onload, onclick, etc.), and external resource references.
• When served as image/svg+xml and rendered by the browser, script nodes and event attributes may execute, creating an attack vector similar to HTML XSS.
• Traditional image validation (file extension checking or naive MIME checks) is often insufficient because SVG content is textual and easy to tamper with.

Affected component and root cause

The root cause is inadequate validation and sanitization of uploaded files combined with serving SVG content directly to users. Accepting and storing raw SVG files without removing scripting constructs or restricting how they are delivered allows attackers to persist malicious scripts inside application-accessible image files.

Impact

• Stored XSS can lead to session theft, account takeover, arbitrary actions on behalf of users, or distribution of malware.
• Because the payload is stored on the application server, any user who accesses the image (or a page embedding it) may be impacted.

Safe detection and verification (responsible testing)

• Do not execute malicious payloads in production. When testing, disable JavaScript in your browser or view the raw source of uploaded SVG files to inspect content safely.
• Use automated scanners and static inspection to detect user-controlled XML elements, <script> nodes, event-* attributes, and <foreignObject>.
• Confirm fixes by checking that uploaded SVG files are sanitized (no scripts or event attributes), or are served in a way that prevents execution (e.g., served as download or rasterized).

Mitigations and recommended fixes

A multi-layered approach is recommended: reject dangerous uploads, sanitize acceptable SVGs, set secure response headers, and consider alternative handling (convert to raster). The following measures should be applied together:

• Whitelist file types: allow only explicitly required formats (e.g., PNG, JPG). If SVG is not needed, disallow it entirely.
• Validate content server-side: do not rely solely on extension or client-side checks. Inspect MIME type and parse the file contents.
• Sanitize SVGs: remove <script> elements, event attributes (onload, onclick, etc.), <foreignObject>, and external references before storing or serving.
• Apply response headers: set X-Content-Type-Options: nosniff and a restrictive Content-Security-Policy (CSP). Consider serving SVGs with Content-Disposition: attachment if they do not need to render inline.
• Rasterize uploads: convert uploaded SVGs to PNG/SVG-safe raster images on upload to eliminate script execution risk.

Practical server-side example — PHP: validate and sanitize SVG uploads

// Example: simplified PHP handler for safe SVG uploads
// 1) Accept file upload
// 2) Allow SVG only if sanitized
// 3) Remove script nodes and event attributes using DOMDocument

function sanitize_svg(string $svgContent): ?string {
    libxml_use_internal_errors(true);
    $doc = new DOMDocument();
    // Prevent external entity loading
    $doc->loadXML($svgContent, LIBXML_NOENT | LIBXML_DTDLOAD); // NOTE: adjust flags safely
    // Remove script elements
    $scripts = $doc->getElementsByTagName('script');
    for ($i = $scripts->length - 1; $i >= 0; $i--) {
        $node = $scripts->item($i);
        $node->parentNode->removeChild($node);
    }
    // Remove event handler attributes (attributes starting with "on")
    $xpath = new DOMXPath($doc);
    $nodes = $xpath->query('//*[@*[starts-with(name(), "on")]]');
    foreach ($nodes as $n) {
        foreach (iterator_to_array($n->attributes) as $attr) {
            if (stripos($attr->name, 'on') === 0) {
                $n->removeAttributeNode($attr);
            }
        }
    }
    // Optionally remove foreignObject elements
    $fo = $doc->getElementsByTagName('foreignObject');
    for ($i = $fo->length - 1; $i >= 0; $i--) {
        $node = $fo->item($i);
        $node->parentNode->removeChild($node);
    }
    // Re-serialize
    return $doc->saveXML($doc->documentElement);
}

// Usage (simplified)
if ($_FILES['image']['error'] === UPLOAD_ERR_OK) {
    $tmp = file_get_contents($_FILES['image']['tmp_name']);
    $finfo = finfo_open(FILEINFO_MIME_TYPE);
    $mime = finfo_buffer($finfo, $tmp);
    finfo_close($finfo);

    if ($mime === 'image/svg+xml') {
        $clean = sanitize_svg($tmp);
        if ($clean !== null) {
            // Save sanitized SVG safely (generate a random name, set proper permissions)
            $filename = 'uploads/' . bin2hex(random_bytes(12)) . '.svg';
            file_put_contents($filename, $clean);
            // Optionally, convert to PNG to be extra safe
        } else {
            // Reject upload
        }
    } else {
        // Handle other allowed image types (validate mime & size)
    }
}

Explanation: This example demonstrates a server-side sanitization approach for SVG uploads. It uses PHP's DOMDocument to parse the SVG XML, removes <script> elements, removes attributes whose names start with "on" (common event handlers), and strips <foreignObject> elements. After sanitization the SVG is re-serialized and stored. Note: when using DOMDocument, be mindful of XML external entity (XXE) risks; ensure external entity loading is disabled and test thoroughly. Use well-maintained libraries where possible.

Improved PHP sanitization using a trusted library

Whenever possible, prefer a maintained SVG sanitization library (for example, an SVG sanitizer packaged for your platform) rather than rolling custom sanitizers. Libraries are more likely to handle edge cases and evolving browser behaviors.

// Pseudo-code showing library usage
// Composer package example (illustrative): enshrined/svg-sanitize
use enshrined\svgSanitize\Sanitizer;

$sanitizer = new Sanitizer();
$dirtySVG = file_get_contents($_FILES['image']['tmp_name']);
$cleanSVG = $sanitizer->sanitize($dirtySVG);

if ($cleanSVG) {
    file_put_contents($destination, $cleanSVG);
} else {
    // reject
}

Explanation: This snippet shows conceptual usage of a PHP SVG sanitization library (actual package names and APIs may differ). Libraries often inspect and remove dangerous tags, attributes, and URIs, providing a more robust baseline than simple ad‑hoc code.

Response headers and server configuration

Add headers that reduce the risk of SVG script execution and content sniffing. Example header suggestions:

// Recommended HTTP response headers
Content-Security-Policy: default-src 'self'; script-src 'none'; object-src 'none';
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: no-referrer-when-downgrade

Explanation: A restrictive CSP with script-src 'none' blocks inline and external scripts on pages that use this policy. Note that CSP must be applied in a way that does not break legitimate application behavior. For image endpoints, consider sending Content-Disposition: attachment if you want to force download rather than in‑browser rendering. Always test headers site-wide to avoid unintended side effects.

Alternative handling: rasterize SVG uploads

Converting user-supplied SVG to a raster format (PNG/JPEG) eliminates script execution risk entirely because raster images cannot contain executable XML/JS. On upload, render the SVG server-side (using a safe renderer) to a bitmap and store/serve only the raster image.

Nginx example: attach safe headers to image responses

# Example nginx configuration (place in server/location block)
location /uploads/ {
    add_header X-Content-Type-Options nosniff;
    add_header Content-Security-Policy "default-src 'none'; img-src 'self';";
    # Optionally force download for SVGs
    if ($request_filename ~* \.svg$) {
        add_header Content-Disposition "attachment; filename=$request_filename";
    }
    try_files $uri =404;
}

Explanation: This snippet configures nginx to serve files under /uploads/ with headers that disable content sniffing and apply a narrow CSP for images. For SVG files, the configuration forces download rather than inline rendering, mitigating script execution risks.

Secure development checklist

• Disallow SVG uploads unless explicitly required by functionality.
• If SVG is required, enforce strict server-side parsing and sanitization (remove scripts, event attributes, external references).
• Use well-tested libraries for SVG sanitization and conversion.
• Apply X-Content-Type-Options: nosniff and a restrictive CSP to image endpoints.
• Store uploads outside the web root or with randomized filenames and strict permissions.
• Limit file size and validate mime types server-side (not only by extension).
• Log and monitor upload activity; alert on suspicious patterns.

Responsible disclosure and mitigation status

For CVE handling, vendors should provide security advisories, patches, and recommended mitigations. If you are an operator of affected software, apply vendor-supplied patches or implement the mitigations above as an interim measure. Maintain secure backups before applying fixes and test in a staging environment.

References and further reading

• OWASP: SVG Security — guidance on SVG sanitization and risks
• Mozilla Developer Network: Serving SVG Files securely and CSP guidance
• Common Vulnerabilities and Exposures: CVE-2024-27744 (vendor advisories and timelines)
• Libraries: enshrined/svg-sanitize (PHP), svg-sanitizer (other languages)